View previous topic :: View next topic |
Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
Bootloader and 3.3V VDD |
Posted: Wed Sep 05, 2007 4:37 pm |
|
|
I implemented a bootloader and while the loader is running my code
verifies the program code by reading it after it has been written.
The loader completes the task.
After it's done I use ICD-U40 to read the program to HEX file.
In the read file I'm finding several lines that contain only FFFF's
Here is an example.
:100280000EF0F29CF29EE824AF0FF66E020EF76EAF
:10029000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6E
:1002A0000800F5500EBCF28C0EBEF28EF96ED6012F
I can confirm that during the programming the line starting with :10029000 would have been verified against the real code.
Yet when reading it with the ICDU-40 it reads all FFFF's
Should I be using LVP ? The chip is running at 3.3V ?
Are here other issue when using a bootloader and system is at 3.3V
Chip is PIC18LF6720 |
|
|
mskala
Joined: 06 Mar 2007 Posts: 100 Location: Massachusetts, USA
|
|
Posted: Thu Sep 06, 2007 6:25 am |
|
|
LVP is not related to writing Flash during program execution.
I have no problems using 3.3V on 18LF chips with bootloader.
In the read back hex file, any byte not programmed will return as FF. Check against your .lst file if there is any code supposed to be there. |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
which bootloader ? |
Posted: Thu Sep 06, 2007 7:30 am |
|
|
mskala wrote: | LVP is not related to writing Flash during program execution.
I have no problems using 3.3V on 18LF chips with bootloader.
In the read back hex file, any byte not programmed will return as FF. Check against your .lst file if there is any code supposed to be there. |
Thanks for the reply, OK about LVP.
Are you using your own bootloader or what are you using?
I'm adapting theByteFactory bootloader, only because it's the easiest to read and understand. Eventually I want to read the file from SD card and cut out the serial link. First I need to get the thing working.
I think the problem stems form the way the code is writing to program memory.
In your boot loader are you writing each location with write_program_eeprom(address, data) or are you using
write_program_memory(address, buf, numbytes) ?
Hans W |
|
|
mskala
Joined: 06 Mar 2007 Posts: 100 Location: Massachusetts, USA
|
|
Posted: Thu Sep 06, 2007 8:37 am |
|
|
It uses write_program_memory(). Bits from various places |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
How does a bootloader work at 3.3V if you can't erase? |
Posted: Thu Sep 06, 2007 10:13 am |
|
|
How does a bootloader work at 3.3V? According to the PIC18LF6720 datasheet page 319 table 26-4 parameter D132 you can't erase the program flash memory at less than 4.5V. How do you write a new program without erasing the old?
I have been using PICs for years, but I am just learning about bootloaders now. All the 18 series PICs I have looked at have the same 4.5V minimum for erasing program flash. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
Thanks |
Posted: Thu Sep 06, 2007 11:22 am |
|
|
mskala wrote: | It uses write_program_memory(). Bits from various places |
|
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
Re: How does a bootloader work at 3.3V if you can't erase? |
Posted: Thu Sep 06, 2007 11:27 am |
|
|
SherpaDoug wrote: | How does a bootloader work at 3.3V? According to the PIC18LF6720 datasheet page 319 table 26-4 parameter D132 you can't erase the program flash memory at less than 4.5V. How do you write a new program without erasing the old?
I have been using PICs for years, but I am just learning about bootloaders now. All the 18 series PICs I have looked at have the same 4.5V minimum for erasing program flash. |
Yes I'm also just doing bootloaders.
Have never needed them before but now it could save a lot of work.
Reading from various places the only thing that needs 5V to erase and reprogram is the configuration bits.
My system will tolerate 5V (by removing jumpers) for erase and reprogram at 5V, but I can't run the chip at 5V because the rest of the system is 3V3 only ! Which means I can't run a bootloader with the chip at 5V it will fry the Bluetooth module.
I'll post a question on the Microchip Tech. support line and give you some feedback when/if I get a response.
Hans W
Last edited by Hans Wedemeyer on Sun Sep 09, 2007 12:20 pm; edited 1 time in total |
|
|
Guest
|
|
Posted: Thu Sep 06, 2007 11:42 am |
|
|
I´m posting this from memory, but i think that 5V are only needed to erase the whole chip at once. If you erase only a page at a time you can do it at lower voltages. This also answers a question from someone who recetly posted that he could only program the pic 32 bytes at a time: there are 2 different limits to consider when writing a bootloader: the erase block size and the write block size. Each pic has different numbers for them (damn microchip). Sometimes they are the same, sometimes the erase block is bigger than the write block, sometimes the opposite happens. You must study this information for your PIC. See AN910 for a good understanding (but not full details) about what happens when you program a PIC. |
|
|
mskala
Joined: 06 Mar 2007 Posts: 100 Location: Massachusetts, USA
|
Re: How does a bootloader work at 3.3V if you can't erase? |
Posted: Fri Sep 07, 2007 7:38 am |
|
|
SherpaDoug wrote: | How does a bootloader work at 3.3V? According to the PIC18LF6720 datasheet page 319 table 26-4 parameter D132 you can't erase the program flash memory at less than 4.5V. How do you write a new program without erasing the old? |
Sorry, I wasn't thinking this through, on one design where system runs at 3.3V, the bootloader is run only from USB power and only turns on the PIC, which is done at 5.0V. My other rs232 bootloader implementation is a system running at 5V also. So I don't know what will happen below 4.5 |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
Erase and Program with VDD - 3.3V and a question |
Posted: Mon Sep 10, 2007 12:08 pm |
|
|
I tested to see if it is possible to erase program eeprom with VDD at 3.3V.
Using erase_program_memory (address) I was able to confirm it does work.
write_program_memory ( address, buf, num ) also works.
With these two items working at 3.vV the bootloader code should also work.
But it does not:
According to the CCS help file for write_program_memory()
if ( getenv("FLASH_ERASE_SIZE") > getenv("FLASH_WRITE_SIZE") )
{
then writing to the block[0] location will erase a block.
}
for the PIC18LF6720 FLASH_ERASE_SIZE is 64 and FLASH_WRITE_SIZE is 8
Test:
Already programmed locations at address 0X0100 :
I the used this statement write_program_memory( 0X0100, buf, 8 )
I then shut down and read the chip back to file using "Read To Hex File"
I expected to see locations 0X0100 thru 0X0107 contain the new values and the remainder of the block 0X0108 thru 0X013FF filled with 0XFF.
That was not the case !
So it appears the automatic erase when writing to lowest location of a block does not happen.
Unless:
I don't understand what or how a block is defined ! I assumed that
FLASH_ERASE_SIZE determined the block boundaries ! Is that a correct assumption ? |
|
|
Guest
|
|
Posted: Mon Sep 10, 2007 12:36 pm |
|
|
you said "it wasn´t the case" but didn´t say what happened. So... what happened? |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
what happened |
Posted: Mon Sep 10, 2007 3:51 pm |
|
|
Anonymous wrote: | you said "it wasn´t the case" but didn´t say what happened. So... what happened? |
What happened is" the 64 bytes of original data are still there ! The block did not get erase.
Some of the data I wrote (8 bytes) was there but as I wrote only 8 byte I expected the remaining 56 bytes to be all 0XFF write_program_eeprom() works sometimes...
Doing erase_program_eeprom(address) does as I expected.
I tried doing erase at each block boundary but that did not work. I expected
it would do what write_program_eeprom() was supposed to do. I also can;t see the assemble in the lst file.. note sure whay write_program_eeprom() is doing.
I've posted a question to ccs tech. support perhaps PCH V3.249 is broken.
As I can't get the PCH V4.xx debugger to work I'm stuck using 3.249.. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Sep 11, 2007 8:25 am |
|
|
Perhaps the compiler is SMART enough to see you only write 8 bytes...
thus it reads in the 64 byte area. does the erase of the 64 byte area,((it has to do it this way)) and then write the new data. BUT it assumes the new data is the old 64 byte with your new 8 bytes.
Just a thought, can anyone check this? |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
Update |
Posted: Tue Sep 11, 2007 3:25 pm |
|
|
Called CCS and got confirmation:
1) Yes it is possible to use write_program_memory() on a 3.3V system.
2) Only thing that cannot be changed is the configuration register which requires 5V to erase.
3) PCH V3.249 has issue with write_program_eprom() and suggested it's best to use PCH V4.055 or later.
I have no time at the moment to battle the PCWH IDE V4 debugger issues so it will be a while before I complete the boot_loader.
Thanks to everyone for the input and help. |
|
|
|