Pumpkin, Inc.

Pumpkin User Forums

DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

If you think you've found a bug or other mistake in your Salvo distribution, post it here.

DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby aek » Fri Jan 31, 2003 1:01 am

quote:
it have to be solved from SALVO side as well
That's what resource locking is for ... this problem is an unfortunate side-effect of the PIC16's hardware design.

I think jtemples' solution (not not pack strings when you've got this potential conflict) is the most expedious way to go ...

quote:
magine that you have to put OS_WaitBinSem before ANY sprintf, or v=ARRAY[n] instruction
It isn't pretty, I agree ... if you can move all EEPROM ops into a task, and use messages to communicate with the task, then it won't be so bad ...

Or, you could use an external EEPROM :-)

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby luben » Fri Jan 31, 2003 7:36 am

Hello,

This could be named: "DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO!"

As I told you I was chasing almost 2 weeks one very strange bug - in my SALVO MONITOR project on the screen appeared from time to time "garbage" symbols (one or twice per hour, sometimes rare then this). My search revealed some other problems, but up to today I didn't figure out from where this could happen. This bug helped me to catch the BANK BUG problem as well, but stayed unrevealed up to today. Because it was only connected with the LCD monitor messages, I didn't worry so much.... but the true is that it's extremely dangerous problem!

Now the "secret of the focus"....

The main problem is that SALVO is multitasking enviornment and HiTech uses compressing of ASCI symbols if they exceed some threshold. Hitech uses from some time ago special approach to compress twice the ASCII symbols (in one program word they put 2 characters) - PIC16 program memory is 14 bits long... exactly 2 ASCII characters could fit there. Nothing wrong with this - it's welcomed.

Be aware - to access the FLASH memory you have to use not the normal way RETLW nn, but you have to READ FLASH memory!!!! And here the problems begin to appear, because if write to EEPROM is still active, the values from the FLASH will be not correct.

In my case the source of the problems is one task that makes "soft background recording of variables". It's a task that wakes up periodically every 20-30 s and if there is change in the variables values record the changes in EEPROM. The idea of such approach is that I use variables in RAM ( for settings, some data, etc.) and with the time they become "hard" - recorded in EEPROM, so, the next time I power up the system they remain unchanged.

In standard, old-fashion linear programming it's not big deal when making programming to wait the end of EEPROM programming and not to do anything more. In SALVO this is REAL PROBLEM, because the usual way to wait is : OS_Delay, OS_Wait, OS_Yield.... that means - other program will take the control.
If one of this programs is so "stupid" to call sprintf, printf, read data from cosnt char array (when ASCII chars are help compressed) it should not blame anybody for the wrong results - the results are INPREDICTABLE. In my case I use arrays to hold strings for display.... even if the message is with mistakes - nobody will be hurt. But if I hold in this ASCII const char arrays commands (to start engine, motor, heater) you can imagine how big disaster could happen.

BTW I asked in the forum of HiTech how I could switch ON/OFF this setting (compressing the ASCI symbols) and they answered me - "Don't worry - HiTech is doing this automatically". Seems that you have to ask HiTech to add one additional switch COMPERSSION ON/Off... or SALVO users always could be in trouble.

I'm 100% sure that the same problem could appear and in linear program, if write EEPROM is not checked for end of operation. Then any sprintf, printf and aceess to const char arrays could yield unpredictable results.

In short - ask Matt to keep the resetbanks() (I really like this implementation) and to allow to the users to chose compression or not of the ASCI strings - do I ask for so much?

Currently I made simple solution (until the next HiTech release) - add in the string one 0xFF (or something >0x80) char that prevent compressing , but did not appear on the screan...... but it's not elegant solution.

I'm afraid that I used several times this "soft record" in EEPROM and I have to inspect this projects - I'm sure that they have hidden "bombs" ticking there, oh, my!

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby luben » Fri Jan 31, 2003 8:18 am

quote:

BTW, salvodemod1 uses packed strings (read-only) on '87X and works fine.


Yes, demo projects are usually running one two times to see how the idea of SALVO is working. They are not working projects. Even if there are problems inside of them, they could stay unrevealed, because they are not run frequently and not monitored long time.

And if something is wrong with demo project it's OK... but if in the car computer the ABS somehow stops working for a while when you have to stop the car - it's different. For sure we have to think from the point view of the "worst case", the most pessimistic view... This is the real danger of the CONST ARRAY problem - it happens from time to time and in some cases it could NEVER happen at all.

quote:

It isn't pretty, I agree ... if you can move all EEPROM ops into a task, and use messages to communicate with the task, then it won't be so bad ...


I revealed this problem into project that uses special task to access the EEPROM - no other tasks have access to the EEPROM at all. It's not the solution.

Regards
Luben

[This message has been edited by luben (edited January 31, 2003).]

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby aek » Fri Jan 31, 2003 8:23 am

Hi Luben.

You underestimate how hard demod1 is tested ... :-)

The reason why it doesn't show up in demod1 is that demod1 does not do any EEPROM accesses.

But you're right about the need for testing ... TEST TEST TEST for production products!

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby luben » Fri Jan 31, 2003 8:35 am

quote:

But you're right about the need for testing ... TEST TEST TEST for production products!


I used to work some projects for testing systems and elements.... I just can say now that IT'S IMPOSSIBLE TO SAY 100% SURE THAT ONE PROJECT IS WORKING. You can only define possibility not to have problems like 0.1%, 0.000001% and so on. Like noting material can move with the light speed, nothing real can have 0% possibility for errors.
And for sure the testing job requires ONLY PESSIMISTS, people with bad mood, angry people, unpredictable people - they speed up the revealing of the problems.
Here we say (it's russian word) "durako ustoichiwost" - the possiblity of one project to survive after meeting an idiot :-)

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby aek » Fri Jan 31, 2003 8:38 am

Hi Luben.

Can you give a code example of where this might happen? This isn't a Salvo problem so much as it is an issue of the mechanisms required when accessing Flash memory ...

And there is a switch for what you want -- it's

quote:
Added -NO_STRING_PACK option to disable string packing optimizations. It was found that some emulators and debugging environments didn't fully support processors which could read their own program memmory. This option is provided to easily disable this feature.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby luben » Fri Jan 31, 2003 9:15 am

Hi,

I'll send the code, but right now I'm leaving the office, so you'll get them after 2-3 hours..

In short it's something like

code:

...
in one task you do...
WR = 1; // start programming of EEPROM
while (WR) {
OS_Yield(..);
}
....

and in another task you make
sprintf("Hello"); // this could yield wrong data if executed immediately after OS_Yiled()


I'll send more detailed code with highlighted problem.

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby jtemples » Fri Jan 31, 2003 9:26 am

I can see this also being a problem when you use interrupt-driven EEPROM write queues (with or without Salvo), since WR could be high for extendend periods of time.
jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby aek » Fri Jan 31, 2003 9:33 am

Hi Luben.

Are we talking EEPROM or FLASH? I think you mean FLASH ... that's where const data is normally placed if string packing is enabled.

Either way, you must follow Microchip's instructions exactly on writing to EEPROM/Flash with the instruction sequence they provide (Chapter 4 of the 16F87X datasheets).

I presume you're trying to do something else while an EEPROM/Flash Write is in progress ... an honorable goal, but you can't violate their timing requirements and expect it to work ... and you are (occasionally) violating timing requirements by re-accessing EEPROM/Flash before the previous write cycle has completed.

Put another way, accessing EEPROM/Flash is not "re-entrant". You may have to live with simply using HI-TECH's functions for accessing EEPROM and endure the wait while the write is happening ...

BTW, salvodemod1 uses packed strings (read-only) on '87X and works fine.

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: DANGEROUS PROBLEMS ACCESSING CONST CHAR ARRAYS within SALVO

Postby jtemples » Fri Jan 31, 2003 10:10 am

If an internal EEPROM write cycle is in progress, you cannot read from flash memory; the read will silently fail, just as Luben saw. I don't believe the PIC datasheets really tell you there's an interaction between the flash and EEPROM modules.

The problem is that Hi-Tech assumes that it is safe to read flash memory at any time with their string-packing code. I don't believe this is a reasonable assumption for the compiler to make as its default behavior. -no_string_pack should be replaced by -string_pack and an appropriate caveat in the manual.

jtemples
 
Posts: 45
Joined: Tue Jul 16, 2002 11:00 pm

Next

Return to Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron