Upload software to Hercules RM48L952ZWT via XDS100v2 and CCS

Hi Anthony,

I was not clear, apologies, as I have 2 different tasks in mind.

1. Debug:

Assuming that I successfully tested the connection in the screen above, and I want to simply debug things, do I just press F11, like I would on an Eclipse project to start debugging, like I would a Java project with breakpoints and all, just I am using the board as a target?

2. Production Upload:

That was actually what I meant, which I believe you addressed, just some questions. I downloaded and installed UniFlash. I then launched the GUI and opened the ccxml associated with my project.

a) Do I understand the usage correctly, namely that once I open the ccxml, I go to the Programs node and add in the OUT file and click on "Program" and then "Verify"?

b) I assume UniFlash automatically knows where in flash to store the code, such that everything executes properly.

c) Do I need to do anything else?

d) What is the purpose of the ability to "Add" more than one output file to the queue/list?

Hi Sarah,

Super - glad you got going with Uniflash.

For your specific Uniflash questions - please post them under the CCS forum.
e2e.ti.com/.../

I've only used it occasionally and not for the same type of work you are doing - but on the CCS forum you'll get the tools experts to respond.
(This forum is more about the Hercules MCU specifically - general tool questions are ok but for example (2d) I have no idea and (2b) I think you need to point to the .out file yourself - so if it automatically pointed there that's a new one to me - sorry. ).

Just one thing to remember about the Hercules parts is that the ECC adds constraints on flash programming that might not be there on other MCUs without ECC because ECC is computed on 8 bytes at a time, so there is a minimum unit and alignment driven by ECC not by flash... If you ever get into that type of problem than that *would* be specific to Hercules and we'd be able to address it better here.

Thanks and Best Regards,
Anthony

ok, shall do, but I am not following your last statement a bit. ECC gets checked automatically by HalCoGen. The build process creates the output file that I upload. To which problem do you refer, which I would/might run into?

Hi Sarah,

Actually - ECC checking is enabled in hardware in HalCoGen but the ECC *content* has to be programmed into the flash during download.

And the content is not generated by HalCoGen. 

It can be generated either by:

   - the linker (best practice)

   - automatically during download by the flash API (default)

The issue you can easily have when programming the flash twice with different files might be this:

Let's say you have some area of memory where it starts off erased like this:

Flash Address                                                        Corresponding ECC

0x____0000   0xFF FF FF FF FF FF FF FF        0xFF                                            <- Erased flash & ecc = ecc error usually

Then you program one, let's say it's from your 1st object file:

Flash Address                                                        Corresponding ECC

0x____0000   0xAA FF FF FF FF FF FF FF        0xXX                                            <- Erased flash & ecc = ecc error usually

So now your ECC is some other value -- don't know what it is but don't care so calling it "XX"

Now if in your 2nd object you try to program another byte within the same 64-bit word:

Flash Address                                                        Corresponding ECC

0x____0000   0xAA BB FF FF FF FF FF FF        0xYY                                            <- Erased flash & ecc = ecc error usually

Then as a normal 'Flash' user you probably already know you can change the data portion from 0xFF -> 0xBB without erasing the sector,

because you are only changing bits from 1->0.     

You probably also understand you cannot then change  0xBB -> 0xFB  without erasing the entire sector and if you do that you need to program the entire sector again too... if you just want the end result to be a single byte within the sector.    This is because 0xBB -> 0xFB requires a change of a bit from 0->1.

Well when you put ECC into the equation -   you've got the issue even if the data itself is just changing 1's -> 0's  to update the ECC value you likely need to change the ECC content so that some bits which were 0 will change to 1...  meaning you'd need to do a sector erase and reprogram on the ECC as well.

This is not something that the programming utilities are smart enough to handle - and when you build if you use the linker to generate ECC but then build two different .out files the linker isn't looking across the two .out files and trying to combine them to 'merge' ECC content.

So you have to be careful that you don't have data in the two .out files that would result in a different ECC value - meaning they should not only 'non-overlap' at the byte level but they should not overlap at the 64-bit word level at all...