 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
| CCS Load: "Erase only blocks in hex file" |
 Posted: Fri Jun 04, 2021 10:10 am |
 |
|
CCS Load has an option "Bulk erase chip before programming" or "Erase only blocks in hex file."
From a topic here (2019), there was a confirmed issue where the "Erase only" option could not be used. This appears to have been fixed, but I am wanting confirmation of a problem I am seeing with it.
I am revisiting a bootloader I wrote, and we wanted to be able to load the Bootloader, then later load the Application code (in a different segment of memory) direct from the IDE. This would greatly speed up our development cycle instead of having to use our bootloader tool each time (plus, we can't use the source debugger that way).
But, we ran in to some snags so I thought I'd share the work so far in case it helps others.
CCS support has been working with me, giving me options like this to put in the base (Bootloader) code:
| Code: | // Erase entire flash part before programming Bootload code.
// 135 = 10000011
// 1 - *PROG
// 2 - *DATA EE
// 4 - CONFIG
// 8 - Erase only blocks
// 16 - Erase chip after write errors
// 32 - Verify ROM protect.
#HEXCOMMENT\SETTINGS OPTIONS=131 VOLTAGE=5.00 |
That makes a HEX file that will bulk erase the entire flash before programming. This lets us put on a Bootloader and start fresh.
Then, in a second overlay (Application) file, it uses:
| Code: | // Only erase portion of flash being used in hex file.
// 139 = 10001011
// 1 - *PROG
// 2 - *DATA EE
// 4 - CONFIG
// 8 - *Erase only blocks
// 16 - Erase chip after write errors
// 32 - Verify ROM protect.
#HEXCOMMENT\SETTINGS OPTIONS=139 VOLTAGE=5.00 |
That "should" erase only the blocks being used in the hex file. It has to do an entire FLASH_ERASE_SIZE block (2K on this part). I did wonder if it would erase the entire 2K if you had hex data anywhere in that 2K area, or if it only did that at the start of the 2K block. My testing shows this may be broken, as it does not appear to erase any part of the 2K block.
Those HEXCOMMENTs can be removed, and the .hex file can be manually loaded using CCS Load by checking off the "bulk erase" for loading the first hex file, then "erase only" for the second.
But the "erase only" doesn't appear to be working as I expect. I came up with this small test:
On a PIC24, as a test, I had one program with an org at 0x0000 and then some ROM code at some address later in memory:
| Code: | #rom int8 0x4300 = { 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa }; |
Then I have a second file with an ORG at a different address, and a different ROM at the same address:
| Code: | #rom int8 0x4300 = { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf }; |
When I load the first .hex, everything is as expected.
When I load the second .hex file, with the "Erase only" option, it does not overwrite the ROM bytes at that address. A verify of the Chip=File shows it expects 0x0-0xf, but sees the original 0xaa.
From just loading code, I verified that it was indeed overwriting the program code without erasing the flash -- new 0's in the bytes would be set, but since it was never erased, new 1's could not be set, ending up with corrupted program code that would crash.
I was actually trying to prove that last bit, when I saw it didn't do anything to the ROM code -- which is odd, in the hex file there is no difference between program code bytes or ROM bytes.
Just passing this on. I'll share the results when it is all figured out.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Jun 06, 2021 8:33 am |
|
|
*** CAUTION - shameless product plug follows ***
You might like to consider one of my bootloaders. They are functionally the same as each other in that each one of them is an incremental bootloader, programming as little as a single byte. It will not allow itself to be overlaid in the bootload process. It does not require the applications reset vector to be moved, nor does it require the application reset vectors to be remapped. You do have to tell the application to reserve the space used by the bootloader.
With this style of bootloader, you develop and debug your code without the bootloader being present. Your application's hex file or files will run identically "as is" on systems with or without the bootloader being present.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Jun 07, 2021 1:03 am |
|
|
I would suspect, that the CCS loader, actually relies on the standard
CCS function's behaviour to automatically erase a block when you write
to the start of it.
What Allen posts, does not write to the start of the block.
So it his array was at 0x4000, I'd expect it to work. However writing into the
middle of a block as he shows, is unlikely to ever work, since it would require
the code to read the entire block, store this, and then change just the bytes
required and write the entire block back.
This ought to really be explained by CCS with regards to this. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Jun 07, 2021 7:28 am |
|
|
| Ttelmah wrote: | I would suspect, that the CCS loader, actually relies on the standard
CCS function's behaviour to automatically erase a block when you write
to the start of it.
What Allen posts, does not write to the start of the block.
So it his array was at 0x4000, I'd expect it to work. However writing into the
middle of a block as he shows, is unlikely to ever work, since it would require
the code to read the entire block, store this, and then change just the bytes
required and write the entire block back.
This ought to really be explained by CCS with regards to this. |
I did test that. It also does not appear to work on the 2K boundary my part uses. However, it does appear the CCS Load problem from 2019 has been resolved.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Jun 07, 2021 7:31 am |
|
|
| asmallri wrote: | *** CAUTION - shameless product plug follows ***
You might like to consider one of my bootloaders. They are functionally the same as each other in that each one of them is an incremental bootloader, programming as little as a single byte. It will not allow itself to be overlaid in the bootload process. It does not require the applications reset vector to be moved, nor does it require the application reset vectors to be remapped. You do have to tell the application to reserve the space used by the bootloader.
With this style of bootloader, you develop and debug your code without the bootloader being present. Your application's hex file or files will run identically "as is" on systems with or without the bootloader being present. |
That sounds like magic. I’ll look at that. We use our own methods of firmware updates, one system using I2C and a new system using Ethernet. The boot loader I wrote works fine, but does not let us load and run via the IDE since it erases everything before it loaded. CCS support gave us the modification to make to IDE options to change that, and that led me down this rabbit hole of other issues.
My solution was just to have our app #import the boot loader code, so as we develop was can load the entire image. That appears to work well, and would be the image we’d send to manufacturing anyway so e needed to figure out how that works at some point anyway.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Jun 07, 2021 8:03 am |
|
|
I have to say I have used another of Andrew's products, and the code is very
good and well supported. So if it sounds as if it might be useful, have a look at
it!..  |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Mon Jun 07, 2021 4:23 pm |
|
|
| Just another satisfied customer of Andrew's. His stuff works. It saves time. It's a bargain. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jun 08, 2021 10:18 am |
|
|
| newguy wrote: | | Just another satisfied customer of Andrew's. His stuff works. It saves time. It's a bargain. |
Good to hear. I've been exchanging some e-mails. Our system has 28 different boards communicating on I2C, so doing a full firmware update over I2C is time consuming. One of the improvements I made to our loader was to skip the 4th byte that is 00, basically cutting the upload time by 25% (not quite, but still faster). We've been discussing what I did to see if there was any way to implement that with his code.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Jun 16, 2021 8:51 am |
|
|
CCS has provided me with updated ICD firmware and a .dll to resolve this issue. I will be testing soon and report my results.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
