Just to be sure, isn’t true that it is not possible locking the MCU flash memory (of code) without locking with it the internal EEPROM?
In other words, it is not possible reading the EEPROM data (saved after running the MCU code for example) if the flash was locked at any level.
I use a standalone parallel programmer to program and read ATmega32.
Thank you.
According to the DS, it depends on how you set the lock bits
in mode 2 you can read flash or EEPROM, but not write using external programmer
if mode 3, you can not read or write to either from the external programmer.
Jim
Thank you Jim.
It is clear then that both (flash and EEPROM) could be read (verified) or not. They are both considered as one block when locking the MCU.
I wished I can read the saved values on EE (by my code) when the board is returned by the user but without having to leave my program unlocked :)
I wished I can read the saved values on EE (by my code) when the board is returned by the user but without having to leave my program unlocked :)
You can if you set the EESAVE fuse bit so it survives a chip erase.
I do that along with recording the SW version number in the EEPROM when I manufacture my boards, then if one is returned, I erase the chip, read the EEPROM to retrieve the stored data,
and if needed, erase again (completely) and reprogram as needed.
Jim
KerimF wrote:I wished I can read the saved values on EE (by my code) when the board is returned by the user but without having to leave my program unlocked :)
You can if you set the EESAVE fuse bit so it survives a chip erase.
I do that along with recording the SW version number in the EEPROM when I manufacture my boards, then if one is returned, I erase the chip, read the EEPROM to retrieve the stored data,
and if needed, erase again (completely) and reprogram as needed.
Jim
Good idea, thank you.
I use a standalone programmer (VP-280, from Wellon-China).
I just like to point out that, as I noticed after many trials, this programmer ignores the setting of EESAVE fuse (ATmega8).
Unexpectedly, it erases both the MCU locked flash and its EEPROM even if the EESAVE fuse was programmed.
this programmer ignores the setting of EESAVE fuse (ATmega8). Unexpectedly, it erases both the MCU locked flash and its EEPROM even if the EESAVE fuse was programmed.
That is a ridiculous assertion. Only if the ISP system would first set fuses to some value of its own choosing (with EESAVE disabled in this case) and then use a sequence not specified by you the user, could this occur.
If the above is true, then I suggest you use an ISP system that does what you tell it to.
Much more likely is a misunderstanding on your part, and you are telling the ISP system to do a sequence of operations that >>appears<< to controadict what you thought should happen.
KerimF wrote:this programmer ignores the setting of EESAVE fuse (ATmega8). Unexpectedly, it erases both the MCU locked flash and its EEPROM even if the EESAVE fuse was programmed. That is a ridiculous assertion. Only if the ISP system would first set fuses to some value of its own choosing (with EESAVE disabled in this case) and then use a sequence not specified by you the user, could this occur. If the above is true, then I suggest you use an ISP system that does what you tell it to. Much more likely is a misunderstanding on your part, and you are telling the ISP system to do a sequence of operations that >>appears<< to controadict what you thought should happen.theusch wrote:
In every trial, I checked the fuses (and lock bits) on the hex file to be programmed.
Then, I deliberately wrote some 0’s in the EEPROM section (0x2000-0x21FF of Atmega8).
After programming the MCU, I read it to ensure it is locked and verify that the fuses (including EESAVE) were indeed properly set.
But the erase button erased both the locked flash and EEPROM (its all bytes returned to FF).
So I am afraid that only those who still have the model I use can confirm if this unexpected behavior is real or not.
On the other hand and for the time being in the least, getting another programmer (or any other tool) is rather impossible where I live.
In every trial, I checked the fuses (and lock bits) on the hex file to be programmed.
For me to be further interested, I would like to see the value of the fuses and lock bits after each step.
How do you read fuses and/or EEPROM contents if the device is locked?
How did you verify that you wrote 0's to EEPROM? With an ..EEP file or equivalent? Or with code?
KerimF wrote:In every trial, I checked the fuses (and lock bits) on the hex file to be programmed.
For me to be further interested, I would like to see the value of the fuses and lock bits after each step.
How do you read fuses and/or EEPROM contents if the device is locked?
How did you verify that you wrote 0's to EEPROM? With an ..EEP file or equivalent? Or with code?
By the way, I write my codes in assembly only. And since I can't have an emulator (at best, I use the simulator embedded in AS6), I have to test every code I develop by running it on its real/end controller board (which I had to design too) to find out my silly bugs. So my first tool I did was writing a small exe program (on DOS, since the only genuine compiler I was able to get and have now is the very old BORLANDC 3.1). This exe appends the state of the fuses and lock bits at the end of the hex file (generated by AS6). And this exe is run by AS6 that activates, soon after compiling the code, a batch file, I specify, that includes their required state (besides performing other tasks on files). Now let me be back to your questions ;)
When the MCU is locked completely, my programmer reads the actual state of its fuses and lock bits (but not the contents of its flash and EEPROM). Is this strange?!
As you know, after loading a hex file the programmer allows editing some bytes on it when necessary (Edit icon). In case of Atmega8, the EEPROM section starts at 0x2000 (512 bytes). If I insert some 0’s in the EE section and disable the lock bits (keep them all as 1’s), reading the MCU after programming it will show these zeros as expected (besides the contents of the MCU flash). But it happens that if the MCU is locked, the programmer erases it all always, no matter if EESAVE was programmed or not. I will likely try to test this on another AVR MCU (other than ATmega8) if available in the local market.
And for the programmer I use, there is no need for an EEP file (which could be generated by AS6). After loading the main hex file, the programmer appends automatically (in its buffer) the EE section while assuming it is all FFs (erased). The programmer inserts this EE section (0x2000 to 0x21FF) between the end of my code and my last (appended) line (0x2200 to 0x220F).
wished I can read the saved values on EE (by my code)
Just to be clear, your program (code) can always read the EEPROM under any and all modes (otherwise why have EEPROM). You could, for example, have your program read and send out any EEPROM desired setting onto a display or out the serial port.
wished I can read the saved values on EE (by my code)
Just to be clear, your program (code) can always read the EEPROM under any and all modes (otherwise why have EEPROM). You could, for example, have your program read and send out any EEPROM desired setting onto a display or out the serial port.
First, I am sorry for my last confusing words. I meant "saved by my code" ;)
And you are right, there is always a way to send out any bytes in EE (and in the flash memory in case it can update itself) via one or more pins. And if there is no free pin to do this, this would need an extra work, based on an idea/solution... out of the box.
AFAIK you cannot read the fuses on a Mega32 when it is locked. So I don't agree with your premises.
Beg/borrow a real setup. Do you mean you use "high voltage parallel programming", or a serial programmer attached to the parallel port of a PC?
Depending on the answer to that, does a known-good ISP program with full facilities support your setup? avr-dude. CodeVision eval edition.
REad back everything after each step. Without that, how do we know that 00 is really being written to EEPROM memory?
Program you AVR with the EEPROM-write test program. Do not lock the chip. Use an ISP program to read EEPROM contents from your chip. Use an appropriate editor to examine that EEPROM contents. Can you find what you have written?
AFAIK you cannot read the fuses on a Mega32 when it is locked.
Locking prevents changing fuses, not reading them. Fuses can always be read.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
AFAIK you cannot read the fuses on a Mega32 when it is locked. So I don't agree with your premises.theusch wrote:
At least Joeymorin (#14) agrees ;)
Beg/borrow a real setup. Do you mean you use "high voltage parallel programming", or a serial programmer attached to the parallel port of a PC? Depending on the answer to that, does a known-good ISP program with full facilities support your setup? avr-dude. CodeVision eval edition. REad back everything after each step. Without that, how do we know that 00 is really being written to EEPROM memory? Program you AVR with the EEPROM-write test program. Do not lock the chip. Use an ISP program to read EEPROM contents from your chip. Use an appropriate editor to examine that EEPROM contents. Can you find what you have written?theusch wrote:
The programmer (VP-280, from Wellon-China, mentioned on #6) is based on the high voltage parallel programming.
I write my codes in assembly only (#10). And each project has one file (*.asm). Its hex file (generated by AS6) ends up onto MCU via USB port of this standalone programmer (which follows the conventional parallel programming). It is as simple as this. I have gained my daily bread since many decades by just doing this (starting from the CPU Z80) ;)
About setting the fuses and append them on the final hex file, I explained it on #10 with the test you proposed now.
Off topic: Although billions of humans are born continuously on Earth, they are forced to live in different worlds (why/how is a big topic). I mean, having a mutual understanding is not always easy :) even if the two sides want to.
About setting the fuses and append them on the final hex file, I explained it on #10 with the test you proposed now
Be careful if you blow a fuse
