Problem loading CPU2 flash image (via SCIA) with serial_flash_programmer (TMS320F28377D)

Hi Robert,

If you are getting the bootloader and kernel to both download successfully, then you must be using the correct SCI pins.

You could set a break point in the VS project for the serial flash programmer before sending the autobaud to CPU2, and then connect to CPU2 and load the CPU2 kernel symbols to see where it is in it process.

Have you locked anything via DCSM on your device?

Regards,
sal

Hi Sal,

Thanks for the feedback. I am just now getting back to this and still having problems with the handoff from CPU1 to CPU2.

We have not locked anything via DCSM.

After the "reset CPU1 and boot CPU2" I am able to attach the CCS debugger and run the CPU2 flash kernel from the beginning. After that the autobaud and load the CPU2 application image works.

I am not sure how to attach the debugger and load the symbols as you suggested (I am somewhat new to CCS as you can tell!) so I am still unable to see what is going wrong with CPU2.

For some reason I cannot run the CPU1 flash kernel using the CCS debugger. It connects and starts to load the image but none of the debugger controls are enabled. The last message I see in CCS is:

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
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.

One other minor problem I noticed is that the autobaud always fails at the higher baud rates. But it always works for 38400 and lower. Is that consistent with what you have observed?

Thanks.

Robert

Using GPIOs that control some LEDs on our board I was able to isolate the problem...

The LED states show that the call to Fapi_setActiveFlashBank() never returns:

GPIO_WritePin(GPIO_LED_ALARM6, 1);
GPIO_WritePin(GPIO_LED_ALARM5, 0);
oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
GPIO_WritePin(GPIO_LED_ALARM6, 0);
GPIO_WritePin(GPIO_LED_ALARM5, 1);

Yet when I use the CCS debugger everything works. Strange!

Any suggestions on where to go from here?

Thanks,

Robert

I need to defer to a team member to respond to this.

sal

To see if it might be a timing problem I tried adding some delays just prior to the call to Fapi_setActiveFlashBank(). No luck.

Any theories as to why it always works when using the debugger?

Is there a way I can borrow the source for the flash API code? With the debugger all I can see is the assembly code.

We do not distribute the source code for the Flash API.

Here are some hints for debugging the issue.

1)      Did you enable EALLOW before calling this function?

2)      Did you seize Flash pump for the respective core before calling this function?

3)      Can you try disabling ECC before calling this function?

4)      Did you password any program to secure flash?  If yes, did you try unlocking before calling this function?  If not, did you make sure to run the API code from the same secure zone as that of the target sector?

5)      Did you make sure to execute all the API functions from RAM?

6)      Did you make sure to assign all the functions in Fapi_UserDefinedFunctions.c to RAM and to the same zone if secured?

7)      Did you make sure to grab FLSEM as required?

Thanks for the list of tips. I will investigate carefully and follow up. I can definitely say we have not used passwords at all.

The code I am running (flash kernel for cpu2) was imported from the controlSuite sample code here:

C:\ti\controlSUITE\device_support\F2837xD\v200\F2837xD_examples_Dual\F2837xD_sci_flash_kernels\cpu02

As I mentioned earlier the problem occurs (consistently) with no modifications to the cpu02 source code. The problem never occurs when I run the flash kernel image using the debugger, i.e., it only occurs after being loaded and invoked by the boot loader.

In response to 1-7 above:

1)      Did you enable EALLOW before calling this function?

2)      Did you seize Flash pump for the respective core before calling this function?

3)      Can you try disabling ECC before calling this function?

Answer is Yes to 1 thru 3 above (see F2837xD_sci_flash_kernel_cpu02 project in the controlSuite sample code)

4)      Did you password any program to secure flash?  If yes, did you try unlocking before calling this function?  If not, did you make sure to run the API code from the same secure zone as that of the target sector?

No. The reason I am certain is because all functionality is working when I run the cpu02 flash kernel using the debugger.

5)      Did you make sure to execute all the API functions from RAM?

I believe so. The linker command file is flash_programming_cpu2_RAM.cmd, which locates everything in RAM, right?

6)      Did you make sure to assign all the functions in Fapi_UserDefinedFunctions.c to RAM and to the same zone if secured?

          I believe answers above cover this (unmodified flash kernel functionality, works with debugger, no security is used)

7)      Did you make sure to grab FLSEM as required?

Yes, the SeizeFlashPump() function (see cpu02 flash kernel source) handles this and CPU2 conditional is correctly defined

Additionally I tried adding some delays and passing different clock rates (such as 200 instead of 150) to Fapi_initializeAPI().

When running without the debugger the cpu02 flash kernel always hangs inside the call to Fapi_setActiveFlashBank(). I believe there must be an infinite loop in there somewhere?

Robert,

There is no infinite loop in the API.

Did you check the password locations and GRABRAM/GRABSECT locations in OTP?  Did you notice anything programmed there?

FLSEM is not handled by the SeizeFlashPump() function.  SeizeFlashPump() handles only the Flash pump semaphore.  Check this out:  https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/525327

Thanks and regards,
Vamsi 

  

Vamsi,

Using the debugger's On-Chip Flash utility I see that the 4 passwords (CSMPSWD0..3) are all ones (0xFFFFFFFF) for both zones

also for both zones:

Z2-GRABSECT is 0x3FFFFFFF
Z2-GRABRAM is 0xF000FFFF


I also tried setting FLSEM per the thread you linked above but still see the problem.

Other ideas?

Thanks,

Robert

Robert,

If not the On-chip Flash GUI utility, you might have programmed via coff file.  Check the password locations, link-pointer location and GRABRAM/GRABSECT using the debugger's memory view window.

Thanks and regards,

Vamsi

Hi Vamsi,

The memory view window shows the following for both zones (and same on both CPUs):

CSM_KEY0: 0000 0000

CSM_KEY1: 0000 0000

CSM_KEY2: 0000 0000

CSM_KEY3: 0000 0000 000F

LINKPOINTER: FFFF FFFF FFFF FFFF....

GRABSECT: FFFF 3FFF

GRABRAM: FFFF F000

Thanks for you patience! I am having a 2nd board configured to see if the same problem occurs there...

Robert

Robert,

All 0s password locks the device permanently.  I asked our security expert to take a look at this.

Thanks and regards,

Vamsi

Robert/Vamsi,

Value pointed out by Robert is of KEYx register which I assume is from CCS flash plug-in GUI. That value being '0' does not mean device is LOCKed. You need to open the CCS memory watch window and check the value at address location 0x78000 to 0x78030 and 0x78200 to 0x78230 and let us know.

Regards,

Vivek Singh

DcsmZ10tp

0x78000

FFFF FFFF FFFF FFFF…..

0x78030

FFFF FFFF FFFF FFFF…..

DcsmZ20tp

0x78200

FFFF FFFF FFFF FFFF…..

0x78230

FFFF FFFF FFFF FFFF…..

I now see that the key (password) values (at 0x5F010 etc) for CPU2 are shown as all zero ONLY when the TMS is in serial boot loader mode. In normal boot mode they are showing up as all ones. Strange!

Thanks,

Robert

Results on 2nd board are exactly the same in all aspects. Can program CPU2 flash using debugger but the call to Fapi_initializeAPI() never returns when using the serial boot loader. CPU1 works great using the serial boot loader.

Thanks,

Robert

Robert,

One thing that I can think is that the gel file disables watchdog when debugger is connected.

Did you try disabling watchdog when you don't use debugger?

Thanks and regards,
Vamsi

Vamsi,

Yes, I tried disabling the watchdog and I also tried disabling interrupts altogether. Same results (works with debugger, hangs in Fapi_setActiveFlashBank() without debugger).

I wish I could figure out where Fapi_setActiveFlashBank() was hanging. Can you tell me which return codes (see Fapi_StatusType enum) are applicable to Fapi_setActiveFlashBank()?

Thanks,

Robert

If possible, could somebody attach a known working CPU2 sci flash kernel image (sci8 .txt format) for the TMS320F28377D?

Thanks,

Robert

Robert,

Did you configure the clock and waitstates correctly before calling the below functions?

Fapi_initializeAPI().

Fapi_setActiveFlashBank().

 

Below are the error return codes applicable to Fapi_setActiveFlashBank() function:

Fapi_Error_InvalidBank - You should pass only Bank0 in your case.

Fapi_Error_InvalidHclkValue - If you configure waitstates correctly per the frequency, then you should not get this error.

Fapi_Error_OtpChecksumMismatch - This occurs if the TI programmed manufacturing data in the OTP is incorrect.  

Thanks and regards,

Vamsi

Robert,

The value you provided for security setting look ok and device is not LOCKed.

On below,

I now see that the key (password) values (at 0x5F010 etc) for CPU2 are shown as all zero ONLY when the TMS is in serial boot loader mode. In normal boot mode they are showing up as all ones. Strange!

This is also ok. Value in KEYx registers are don't care unless passwords are programmed.

Regards,

Vivek Singh

Thanks for the info Vivek that is very helpful.

Vamsi,

Our TMS320F28377D is running at 200MHz.

For clock settings I have tried passing both 150 and 200 to Fapi_inializeAPI().

For wait states I am using the default per controlSuite sample code (in F2837xD_SysCtrl.c):

Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x3;

Are there other clock related settings I need to check?

Thanks,

Robert

Robert,

Did you figure out the error code returned by the API function?

Do you see any toggles on the XRSn pin?

What is CPU1 doing when CPU2 is executing the API?

Thanks and regards,

Vamsi

Hi Vamsi,

Good questions. We are going to investigate with a scope tomorrow and I will follow up. At this point I am guessing this is something unique to our board design (still very early in development), probably related to reset handling.

Thanks again,

Robert

Using a scope we see one toggle of XRSn (intentional) prior to running serial_flash_programmer, but no toggles on XRSn pin while running the serial_flash_programmer. 

After CPU2 handoff, CPU1 is executing where expected, in this spin loop in SCI_boot.c:

while(IpcRegs.IPCSTS.bit.IPC5 != 1)
{
    //
    //continues until CPU2 application is finished
    //
}

After CPU2 hangs in the call to Fapi_setActiveFlashBank(), I can run the cpu2 flash kernel image with the debugger. This appears to cause an internal reset of CPU2 with no reset of CPU1. After running the cpu2 flash kernel image with debugger the call to Fapi_setActiveFlashBank() returns and I am able to autobaud, load the CPU2 application to flash, and run CPU2. After running CPU2, CPU1 then exits the spin loop above.

So we have ruled out external reset, but it appears that some sort of internal reset of CPU2 is required in order for the CPU2 flash kernel to run successfully. Is there a way to do that without using the debugger?

Thanks,

Robert

Hi Robert,

On other questions -

After CPU2 hangs in the call to Fapi_setActiveFlashBank(), I can run the cpu2 flash kernel image with the debugger.This appears to cause an internal reset of CPU2 with no reset of CPU1.

CPU2 gets reset when you connect to debugger or after running the cpu2 flash kernel image?

So we have ruled out external reset, but it appears that some sort of internal reset of CPU2 is required in order for the CPU2 flash kernel to run successfully. Is there a way to do that without using the debugger?

CPU1 can reset the CPU2 by setting RESET bit in CPU2RESCTL register and you could try adding this step in your CPU1 code but I think CPU2 will go in same state after reset because no application code has been run.  It look like something else is missing in this flow. When you connected debugger, some of the initialization is done by CCS gel file and also BOOTROM code execution get skipped. You may want to run the setup with debugger same way as it's run with-out debugger and check where the issue is.

Regards,

Vivek Singh

Vivek,

Thanks for the debug procedure for standalone bootmode.

I won't be able to try it until this Friday at the earliest but I will follow up afterward as soon as possible.

Thanks again,

Robert

I now have a working cpu02 flash kernel image!

Using the standalone debug procedure I could see that cpu02 was somehow getting back into the boot ROM but could not see why.

After inspecting the .map file I tried removing some of the "ramfuncs" code placement declarations. This enabled me to get beyond the autobaud step and into the DFU2 processing. Removing all of the "ramfuncs" declarations (for cpu02) seems to have resolved all of the issues (more testing required).

Thanks for all of the valuable tips! It is much appreciated.