Uniflash F28M35 program fail - wrong clock

Nigel,

The allowed clock for Concerto is limited based on the part that is detected by the Flash Programmer. Based on my information, the F28M35H52C1 part should support a higher clock speed that the value you are currently using.

So, the Flash Programmer must be detecting your device as a different part. If you generate the DS logs (instructions: http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv4#Debug_Server_Logging), I can help you look into what the Flash Programmer is detecting as the part, but it might not help with figuring out what the underlying problem is.

Thanks,
Ricky

Ricky,

I can't run Eclipse, I can only run Uniflash so the debug_server_logging does not help me.

I ran CodeSkin C2Prog and managed to program the M3 core with out a problem but failed to program the C28 as it came up with an error when it tried to erase the flash, see attached image.

I did note that the Chip ID, Chip Rev and Flash API are the same as those reported on chips I can successfully program.

Regards

Nigel

I was mistaken the chip rev is different, the ones I can successful load have a chip rev of 8900, the failure occurs on chip rev 8902

Nigel,

The logging instructions I sent were for CCS; it just so happens that UnIFlash has the same logging mechanism. So instead of starting eclipse.exe, you should start UniFlash instead in the instructions. Everything else should be the same.

I don't know anything about CodeSkin so I can't comment on that, but since you noticed that the revision is different, I think this is probably the cause of the problem. In UniFlash, you can try modifying the clock settings to get a lower system clock speed to work around this issue.

Thanks,

Ricky

Ricky,

I tried running Uniflash with the Dbgview with no success. I will try some different settings in Uniflash and let you know if this works. Question - how do I find out what the differences in Rev consistof? My original devices had rev 8900 while the newer ones have 8902.

Nigel,

The Flash Programmer code in UniFlash reads a bunch of registers on the device to determine the part it is talking to, which allows it to determine how to handle Flash operations, including checks for clock settings. I'm not entirely sure where CodeSkin is getting the revision number from, but I wonder if the 0x2 means you are using RevB devices. Although it that case, I would expect that UniFlash would not detect the device properly (if you haven't applied the patch), or it would just work (if you did apply the patch), instead of the clock setting errors you are getting.

The patch I am referring to is this: http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/251698.aspx. Please read the thread over and determine if you need to apply the patch or not.

Thanks,

Ricky

Ricky,

I applied the patch and can now program the M3 core. However I get the following error when trying to program the C28 Core:

[10:17:32] ERROR >> C28xx_0: Flash Programmer: Error acquiring the pump semaphore, the other core has access to it. Flash Programming cannot be completed. Operation Cancelled.

Nigel

Ricky,

Have successfully reprogrammed my 2 boards, the patch seems to have worked. I do not know what caused the above failure, the only difference is that I relaunched Uniflash and tried again.

Nigel,

Great to hear that you have resolved the issue. I was looking at the semaphore issue internally, but it sounds like you were able to bypass it. Just FYI, the F28M3x devices share semaphores between the C28 and M3 cores to prevent being accessed at the same time, and it seems in your previous case, the semaphore was not released properly by the M3 core after the Flash operation. Restarting UniFlash and reconnect to the two cores, or power-cycling the device should resolve the issue.

Also note that the patch you applied for supporting Rev A/Rev B devices will be included by default in the next UniFlash release. So you will not need to continue to apply the patch if you decide to upgrade UniFlash in the future.

Thanks,

Ricky

Ricky,

I spoke to soon. I have one file that will load, all other files I attempt to load come up with the semaphore error. Here is the error I'm getting:

[08:53:09] C28xx_0: Loading Concerto M3 flash kernel, this may take a few minutes...

[08:53:11] C28xx_0: Concerto M3 flash kernel has been successfully loaded.

[08:53:19] C28xx_0: loading Concerto C28 flash kernel, this may take a few minutes...

[08:53:51] C28xx_0: Concerto C28 flash kernel has been successfully loaded.

[08:54:01] C28xx_0: Erasing Flash Bank 0, Sector N

[08:54:04] C28xx_0: Erasing Flash Bank 0, Sector M

[08:54:06] C28xx_0: Erasing Flash Bank 0, Sector L

[08:54:08] C28xx_0: Erasing Flash Bank 0, Sector K

[08:54:11] C28xx_0: Erasing Flash Bank 0, Sector J

[08:54:13] C28xx_0: Erasing Flash Bank 0, Sector I

[08:54:15] C28xx_0: Erasing Flash Bank 0, Sector H

[08:54:18] C28xx_0: Erasing Flash Bank 0, Sector G

[08:54:20] C28xx_0: Erasing Flash Bank 0, Sector F

[08:54:23] C28xx_0: Erasing Flash Bank 0, Sector E

[08:54:25] C28xx_0: Erasing Flash Bank 0, Sector D

[08:54:27] C28xx_0: Erasing Flash Bank 0, Sector C

[08:54:30] C28xx_0: Erasing Flash Bank 0, Sector B

[08:54:32] C28xx_0: Erasing Flash Bank 0, Sector A

[08:54:33] C28xx_0: Data has been buffered at the beginning of the current data block for 64-bit aligned writes.

[08:54:43] C28xx_0: Verifying Flash @ Address 0x0010AA2C of Length 0x00000018

[08:54:44] C28xx_0: Finish Writing Flash @ Address 0x0010AA2A of Length 0x0000001A

[08:54:44] C28xx_0: Writing Flash @ Address 0x00100000 of Length 0x00003FF8

[08:55:10] C28xx_0: Verifying Flash @ Address 0x00100000 of Length 0x00003000

[08:55:21] ERROR >> C28xx_0: Error during Flash programming (Flash algorithm returned error code). Operation cancelled.

[08:55:21] ERROR >> C28xx_0: Error Writing Flash @ Address 0x00100000 of Length 0x00003FF8

[08:55:21] C28xx_0: Writing buffered data @ Address 0x0010AA28 of Length 0x00000004

[08:55:21] ERROR >> C28xx_0: Flash Programmer: Error acquiring the pump semaphore, the other core has access to it. Flash Programming cannot be completed. Operation Cancelled.

[08:55:21] ERROR >> C28xx_0: GEL: File: L:\IOMAX\CIRIT\Software\sw_snapshot_20130715_1613\CTU_c28.out: Load failed.

[08:55:21] File: L:\IOMAX\CIRIT\Software\sw_snapshot_20130715_1613\CTU_c28.out: Load failed.
[08:55:22] Operation Writing flash memory returned.

Nigel

Additional information.

On the file that will load the first write is:

[09:00:36] C28xx_0: Writing Flash @ Address 0x0010AA7C of Length 0x0000001A

On the files that fail the first write is:

[09:29:04] C28xx_0: Writing Flash @ Address 0x0010AA2A of Length 0x0000001A

Nigel,

Can you try to perform a Flash operation on the M3 core first before loading the program on the C28 core? I want to make sure the M3 core has the chance to release the semaphore correctly. A Flash operation can be either a program load or a Flash erase.

I'm not sure why some programs would work while others don't. Would it be possible for you to send these programs to me for testing purposes if we can't resolve it with my current suggestion?

Also, I just realized you were using the Serial connectivity; this does bring a little more complexity than the standard JTAG solution.

Thanks,

Ricky

Ricky,

Programming the M3 first has no impact on the behavior.

As stated earlier the difference between a file that loads and a file which doesn't appears to have something to do with the address at which it first writes.

For a file which loads this is [09:00:36] C28xx_0: Writing Flash @ Address 0x0010AA7C of Length 0x0000001A

For a file which fails this is [09:00:36] C28xx_0: Writing Flash @ Address 0x0010AA7C of Length 0x0000001A

These addresses appear to come from the map file associated with the build process. Excerpts from those map files are as follows:

for the one that passes:

.flashfuncs

*          0    0010aa7c    0000001a     RUN ADDR = 0000b606

                  0010aa7c    0000001a     Boot.a28FP : Boot.o28FP (.flashfuncs)

binit @ 0010b00c records: 1, size/record: 8, table size: 10

                .flashfuncs: copy 26 bytes from load addr=0010aa7c at page=0 to run addr=0000b606 at page=1

 for the one that fails: 

.flashfuncs

*          0    0010aa2a    0000001a     RUN ADDR = 0000b608

                  0010aa2a    0000001a     Boot.a28FP : Boot.o28FP (.flashfuncs)

binit @ 0010afbc records: 1, size/record: 8, table size: 10

                .flashfuncs: copy 26 bytes from load addr=0010aa2a at page=0 to run addr=0000b608 at page=1

We can send you copies of the files, however we would prefer to send them direct to you rather than post them here if you supply us an email address.

Nigel

Nigel,

Thanks. My email address is in my user profile.

Thanks,

Ricky

Nigel,

I'm actively looking at this.  To help narrow down the issue, I need to know the exact version of the silicon that you have(0, A, or B).  In the errata sheet on page 5 there is a guide for determining which revision of silicon you have:

http://www.ti.com/lit/er/sprz357e/sprz357e.pdf

Also you mentioned that some devices work and other don't.  Could you create a little table that showed me which devices worked and what revision they were?  I believe there is an errata with the PLL that is causing us problems when we go to program.

Regards,

Trey,

The devices that have no issues are YF-24AVD3W

The devices that we are having issues with are YFB-34C9VCW

Attached are images of the device part marking.

Nigel,

Thanks for posting that information.

We believe we've narrowed down the issue to a small bug in the flash programming code which is preventing the PLL from being set correctly.  This in turn causes the baud rate to get slightly messed up which corrupts communications and causes the flashing process to fail.  We are working on a fix which should be available shortly.

Best Regards,

Trey,

Thanks for the update. Do you know the time frame for the fix being available? I'm under pressure to fit an external jtag port to the unit design but if this fix will be available in the very near future I can avoid this.

Thanks for your support.

Nigel

Trey,

Thanks that would be great.

There is another issue that we are struggling with, we are seeing different behavior on the EMAC between Rev0 devices and RevB devices, the RevB devices are taking 150sec to come up on EMAC - see posting

http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/281663.aspx

and I was wondering if you know of someone that could help us with this.

Nigel