F28m35 serial programming with C2Prog and UniFlash

Tamas,

Could you give us more information about the failure you're seeing with Uniflash?  What exactly does Uniflash do when it fails?  What hardware are you running this on? controlCARD?  If so, are you connecting Uniflash to GPIO 0 and 1 for serial comms?

Regards,
Trey

Hello Trey,

UniFlash successfully load the M3 flash kernel. The problem occurs when it starts the program loading to the flash and it always stops at 86%. I am using a controlCard and I connected UniFlash to GPIO0 and GPIO1.

[16:23:09] Cortex_M3_0: Loading Concerto M3 flash kernel, this may take a few minutes...
[16:23:18] Cortex_M3_0: Concerto M3 flash kernel has been successfully loaded.
[16:23:35] Begin Writing Flash memory operation...
[16:23:35] Loading program: C:\m3.hex

Earlier I have tried C2prog as well, but as I mentioned it also crashes with an error code. On the other hand, C2Prog works with another M3 code. So it is also possible that my hex file is not proper ( intel-hex 16 bit version). What do you think?

Thank you and Regards,
Tamas

Tamas,

I personally have tested loading both the M3 and C28 using Uniflash serial (I wrote all the embedded parts of that software :-) ), so I know it works but there could be bugs we never uncovered.

Can you try loading using an out file?  I believe Uniflash can parse out-files. That ought to remove any uncertainty due to file formats.

Trey

Trey,

I've managed to program the uC with the .out file. I am very glad, thanks for the suggestion. However, the program loading also stopped for a while at 86%. Anyway, when the programming with the hex file stops at 86% I see some traffic from the feedback leds but after a 10 minutes I cancelled the process.

I have created the hex file from out with this command:   hex470.exe -i m3.out -o m3.exe -order MS -romwidth 16

What's wrong with the hex file?

Tamas

Tamas,

Not sure...looks like you are generating the hex file correctly.  I am consulting with the co-author of this software...standby for a resolution.

Trey

Tamas,

We've got a couple ideas.  First off, do you mind sending us the hex file?  If it contains proprietary data then don't worry about it, we can approach this from other vectors.

Can you re-run this test after turning on the verbose option? If you scroll all the way down in Uniflash you should see it.  Try setting up a flash operation right before you leave work and let it run overnight.  Then report any errors back to us.

Trey

Hello Trey,

Unfortunately, I'm not allowed to send you the company hex file. But in the morning I was curious about this verbose option. I saw that after UniFlash stopped at 86% the programming continued but it was very slow. Writing 32 bytes took 9 seconds. And writing the 54kB whole program took two and a half hour, moreover the program didn't work.

[09:53:01] Cortex_M3_0: Writing Flash @ Address 0x00201040 of Length 0x00000020
[09:53:09] Cortex_M3_0: Verifying Flash @ Address 0x00201040 of Length 0x00000020
[09:53:10] Cortex_M3_0: Finish Writing Flash @ Address 0x00201040 of Length 0x00000020
[09:53:10] Cortex_M3_0: Writing Flash @ Address 0x00201080 of Length 0x00000020                    <---- next address is greater with 0x40

In the programmed flash memory I see alternately 32 bytes valid data and 32 bytes FF but I realized that it just works according to my hex file.

:20 9640 000520C4FD04F12046FCF73846D6FD0029F8BD68B18368D469234005D11C010832D6
:20 9680 00A7FFC04604400446007A2046C1FA642002E0FCF710BD20002000002004460028FD

Maybe, my hex-file is not appropriate? And why takes the programming so long?

Br,
Tamas

Trey,

I've changed the rom width to 32 as you suggested. Now the generated hex file is correct and I've managed to program the flash. The programming time is also decreased a lot. The whole programming process of the M3 core takes only 6 minutes.

Thank you very much for the help! I really appreciated your fast replies and your great suggestions!

Last question, can I improve somehow the programming speed or it is the usual one at 115200 baud rate :)?

Tamas

Tamas,

Glad to hear that fixed it.  I'm talking with the CCS guys in order to get this fixed in future versions.

All the testing was done at 115200 so for reliability I would recommend that for now.  I'm fully aware that serial programming is painfully slow and this is something we want to improve.  We will be looking at speeding up this tool later this quarter or early 2nd quarter.

Trey