CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

CCS Load: "Erase only blocks in hex file"

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 491
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

CCS Load: "Erase only blocks in hex file"
PostPosted: Fri Jun 04, 2021 10:10 am     Reply with quote

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) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
asmallri



Joined: 12 Aug 2004
Posts: 1608
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sun Jun 06, 2021 8:33 am     Reply with quote

*** 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: 17322

View user's profile Send private message

PostPosted: Mon Jun 07, 2021 1:03 am     Reply with quote

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: 491
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Jun 07, 2021 7:28 am     Reply with quote

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) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
allenhuffman



Joined: 17 Jun 2019
Posts: 491
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Jun 07, 2021 7:31 am     Reply with quote

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) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 17322

View user's profile Send private message

PostPosted: Mon Jun 07, 2021 8:03 am     Reply with quote

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!.. Very Happy
newguy



Joined: 24 Jun 2004
Posts: 1752

View user's profile Send private message

PostPosted: Mon Jun 07, 2021 4:23 pm     Reply with quote

Just another satisfied customer of Andrew's. His stuff works. It saves time. It's a bargain.
allenhuffman



Joined: 17 Jun 2019
Posts: 491
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Tue Jun 08, 2021 10:18 am     Reply with quote

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) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
allenhuffman



Joined: 17 Jun 2019
Posts: 491
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Jun 16, 2021 8:51 am     Reply with quote

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) www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC programmer.
www.whywouldyouwanttodothat.com ?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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