F28377D: Unable to load program to CPU2

Hi Bui,

Duy BUI said:

Pac2_cpu1_bm.out and Pac2_cpu2_bm.out

Would it be possible to provide the out files you are trying to load? If you do not wish to post it publicly, please start a private conversation with me.

Thanks

ki

Hi Ki,

Thank for your reply.

Since my last post, I have tried to load the ControlSUITE example (blinky_dc) and it gives the same result. When compiled with RAM version, both out files for CPU1 and CPU2 can be loaded and run. But when compiled for FLASH version, I can't load into FLASH of the CPU2 (same error displayed in my first post). For the CPU1 it can be loaded and run in FLASH (Standalone or debug version) without problem.

There is probably a problem with my electronic board as blinky_dc run flawlessly with the eval board. But I don't know which mistake can lead to such problem. The JTAG connection seems ok as I can get access to both CPU (read/write to RAM memories, registers...). I also tried with another board, so I don't think that the CSM is accidentally modified.

The device is TMS320F28377DZWTT  YFC-64AXD7W  GI with a 20MHz Quartz.

Hope you can give some ideas what to do.

Thank in advance.

Duy

Ki:
I had a similar problem with the F28377S Launchpad on CCS 6.2 - my F28069 USB Stick will work under CCS 6.2 - I just figured it would be sorted out when CCS moves to version 7, so I have not tried anything else with CCS 6.2 - I am pretty sure the Launchpad worked with CCS 6.1.x

Hi Duy,

Judging from your explanation on how you only have an issue with programming the FLASH on CPU2 on your custom board while there are no issues with with an eval board (controlcard?), it sounds like there is an issue with the flash device. I'll see if our flash programming expert can confirm this.

Duy BUI said:

I also tried with another board, so I don't think that the CSM is accidentally modified.

Did you try this with another custom board? And programming in FLASH worked fine for CPU2 also?

Thanks

ki

Duy, 

Let's try the following:

1. Turn on logging
2. Full erase on both core
3. Load flash on core 2 with core 1 empty and halted

And then send us the logs.

You can also give it a try with uniflash cloud which always hosts the latest code and fixes at: https://dev.ti.com/uniflash

how to turn on logs for CCS: 

how to turn on logging in uniflash: 

Victor

Hi Ki,

I did try with 2 other custom boards and they have the same issue.

I did not have problem with the eval board (controlcard R1.3) which has 28379D (I have 28377D on my custom board).

The issue is always the same: programming flawlessly on CPU1 but cannot erase/write on CPU2.

Best regards,

Duy

Hello Victor,

Thank for reply,
I don't know how to separate the 2 operations (erase and load flash) with CCS6 and On-chip Flash Tool. So I made only a "Erase and Program", how can I upload the ds.log file (20Mb) ?
I also tried with uniFlash 4.1.1078 and got the same error (Error -1135 @ 0xC0CC and Error -1044 @ 0x0).

Duy

To erase core in CCS: 

go to the right core and click on the "erase flash".

In uniflash, go to "Settings and Utils" tab and there is something similar.

Also, to log minimally, shut down and restart the application, then turn on the log, reproduce your issue, and then turn off your log. Don't do anything extra in between.

Hi Victor,

Here is the ds.log from UniFlash. Only 2 operations are performed: erase flash CPU1 then erase flash CPU2.

The console displayed:

[19/12/2016 17:03:59] GEL: C28xx_CPU2: GEL Output: Memory Map Initialization Complete
[19/12/2016 17:03:59] GEL: C28xx_CPU1: GEL Output: Memory Map Initialization Complete
[19/12/2016 17:04:00] Status: C28xx_CPU2: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
[19/12/2016 17:04:00] Status: C28xx_CPU1: If erase/program (E/P) operation is being done on one core, the other core should not execute from shared-RAM (SR) as they are used for the E/P code. Also, CPU1 will be halted to determine SR ownership for the CPU which will run the Flash Plugin code, after which CPU1 will be set to run its application. User code execution from SR could commence after both flash banks are programmed.
[19/12/2016 17:04:00] Status: C28xx_CPU1: Erasing Flash memory...
[19/12/2016 17:04:05] Status: C28xx_CPU1: Operation completed successfully.
[19/12/2016 17:04:18] GEL: C28xx_CPU2: GEL Output: Memory Map Initialization Complete
[19/12/2016 17:04:18] GEL: C28xx_CPU1: GEL Output: Memory Map Initialization Complete
[19/12/2016 17:04:19] Status: C28xx_CPU2: Erasing Flash memory...
[19/12/2016 17:04:20] Status: C28xx_CPU2: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 6.0.504.1)
[19/12/2016 17:04:20] Status: C28xx_CPU2: Trouble Halting Target CPU: (Error -1135 @ 0xC0CC) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 6.0.504.1)
[19/12/2016 17:04:20] Status: C28xx_CPU2: Unable to determine target status after 20 attempts
[19/12/2016 17:04:20] Status: C28xx_CPU2: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
[19/12/2016 17:04:25] Status: C28xx_CPU1: Error: (Error -1044 @ 0x0) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 6.0.504.1)
[19/12/2016 17:04:25] Status: C28xx_CPU1: Error: (Error -1135 @ 0x3FF16A) The debug probe reported an error. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation. (Emulation package 6.0.504.1)
[19/12/2016 17:04:25] Status: C28xx_CPU1: Unable to determine target status after 20 attempts
[19/12/2016 17:04:25] Status: C28xx_CPU1: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not read 0x0007026D@Data: target is not connected
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not write 0x0005F444@Data: target is not connected
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not read 0x0005F444@Data: target is not connected
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not read 0x00130@Program: target is not connected
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error writing the PLL values. (Flash algorithm returned error code). Operation cancelled.
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not write 0x0005D200@Data: target is not connected
[19/12/2016 17:04:41] Status: C28xx_CPU2: Flash Programmer: Error initializing device. Please check if the device is locked.
[19/12/2016 17:04:41] Status: C28xx_CPU2: Error occurred during flash operation: Could not write register PC: target is not connected

7534.ds.log

Did you lock the core? Check at address 0x5f010 for 4 32bit words, which is the password for flash zone1, these shouldn't be set to anything other than all Fs. If you did set a password, you need to enter it in the GUI and unlock it every time you try to connect to the device.
do the same for zone 2, which starts at 0x5f050 for 4 32bit words

These security fields are written into OTP memory which is basically write once so you can't freely change them afterwards. Each bit can be set from 1 to 0 once only.

Hi Victor,

I always take care not to lock the CPU, and I have the same problem (cannot erase CPU2 flash only) on my 3 boards and here what I found on 3 boards (with memory browser):

0x0005F010 DcsmZ1Regs_Z1_CSMKEY0
0x0005F010 0000 0000
0x0005F012 DcsmZ1Regs_Z1_CSMKEY1
0x0005F012 0000 0000
0x0005F014 DcsmZ1Regs_Z1_CSMKEY2
0x0005F014 0000 0000
0x0005F016 DcsmZ1Regs_Z1_CSMKEY3
0x0005F016 0000 0000 000F

0x0005F050 DcsmZ1Regs_Z2_CSMKEY0
0x0005F050 0000 0000
0x0005F052 DcsmZ1Regs_Z2_CSMKEY1
0x0005F052 0000 0000
0x0005F054 DcsmZ1Regs_Z2_CSMKEY2
0x0005F054 0000 0000
0x0005F056 DcsmZ1Regs_Z2_CSMKEY3
0x0005F056 0000 0000 000F

I have these same values for both CPU1 and CPU2 (they are 0x0000 and not 0xFFFF) but I don't think I can read these values as they are password.

I also check the control card and get the same values as above (I can erase/write on both CPU flash of the control card).

Duy,

Good to know that you got it in a workable state.

We did narrow down the investigation to emulation issues from your logs and we are now trying to get the emulation team to look into this. But since this is the holiday season the turn around time will be slow as most people are away on vacations.

Victor