F28069 Flash API works when downloaded from CCS, not from Uniflash

Stuart,

Hrmmm....that's very strange.  Uniflash and CCS using the same underlying software to do flash operations on these devices.  My best guess is some type of clocking issue.  Can you take a look at the PLL registers in each case and see if they are different.  Timing is very critical to the flash operations.

BR,

Trey,

Thanks for jumping in on this.  After some additional debugging with the customer, we determined that we had a MAJOR linker command file issue with regard to defining the locations of all the special function registers in the device.

If we start with a blank flash, everything is now working okay.  However, after fixing this issue based on the ControlSuite example project, one issue still remains.

Once calling the function "Flash_Erase()", which is part of the FLASH API strored in the F28069M (Motion) ROM, we notice that we get stuch at address 0x3FF4FA.  Based on our initial analysis, this apears to us to be a watchdog reset.

SCSR = 0x0005

WDCR = 0x0080

Next we made an attempt in the user callback hook that should be called periodically to clear the watchdog through the WDKEY register.  Through additional debugging, we determined that we get a watchdog reset before we even get to the user callback hook.

Next we added code to explicitly disable the watchdog ahead of the Flash_Erase() call.  We confirmed this by through the debugger just ahead of stepping into Flash_Erase().

WDCR = 0x0040

We also confirmed that the watchdog was already disabled anyways without our additional disable code earlier in the startup of th program.  Just to be safe, we added a "DINT" statement before the sequence of explicitely disabling the watchdog and calling Flash_Erase().

Somehow, the watchdog is getting re-enabled during the Flash_Erase() call.  Despite the Watchdog reset, the FLASH does actually get erased.

Do you have any insight into what we might be doing wrong here that is causing the watchdog to be enabled and a reset to occure.  Is it possible for me to get a copy of the Flash API source (to review privately and not share with the customer)?

Thanks,

Stuart

 

Trey,

We are still experiencing issues with flashing the device when the code is downloaded through the UniFlash tool.  The customer indicated to me today that they are under a severe time crunch to get this resolved and asked that we work with them on this tomorrow (Thrusday June 11).  Could we get someone from the apps team involved who can perhaps webex with the customer tomorrow to try and get to the bottom of the issue.

Additionally, we also still have the problem of branching to an infinate loop in when using the erase API.

Unfortunately I have a prior commitment for tomorrow and will not be able to work the issue.  I do have some drive time in the morning and can check in then.

Thanks,

Stuart

The customer provided the following photo of the device in order to verify the silicon rev.  Additionally they had this to add:

Also, when programming with uniflash, the Flash_Program API call returned with Status 30, should be 0. Code ran through without any hangs but flash not written to.

 

With CCS build/program, all is written to as expected

I'm assuming the above is with the Flash_Erase API commented out.

 

 

 

 

Thanks,

Stuart

Stuart,

1. Address location 0x3FF4FA corresponds to wait_boot function in BOOT ROM. You shouldn't get to this function unless there is a device reset (may be watchdog reset).
2. Different ways you can get into wait boot after a device reset
   1. With JTAG connected: 
      1. 1. if EMU_KEY register, 0xD00 is not equal to 0x55AA
         2. if EMU_KEY register, 0xD00 = 0x55AA and EMU_BMODE register, 0xD01 = 0x2
   2. With JTAG disconnected:
      1. 1. GPIO37 = 1 and GPIO34 = 0
3. I checked Flash_erase function in API, within the Flash_erase() we do disable the watchdog. So, I don't think Flash_erase() is one re-enabling watchdog.
4. I'm wondering whether CPU is reading an illegal opcode, as reading illegal opcode would trigger ITRAPIsr which inturn enables WD causing WD resets. Have you already checked this?
   1. if PIE enabled, 0xD26 should point the ITRAPIsr function address
   2. if PIE disabled, 0x3FF781 should point the ITRAPIsr function address
5. Hope the customer is running all flash related algorithm from RAM. If you check the example flash API project, we run all the flash related algorithm from RAM after using Example_MemCopy function. You CAN'T run flash algorithm from flash. Even this might cause illegal instruction fetch.
6. Please make sure your code follows these guidelines.

Regards,

Manoj

Manoj,

My understanding (confirmed in the product litterature) was that the FLASH APIs in the F28069M devices is in ROM not FLASH, therefore not requiring them to be transfered to and run from RAM.  There is even a comment refering to this within the example code project.  Is this not the case?  What is actually required to be run from RAM in these devices?

Thanks,

Stuart

Stuart,

Please check the flash api example. In that example, Example_CallFlashAPI() function which inturn calls Flash_erase, Flash_program (or) any flash API function should be run from RAM. This Example_CallFlashAPI() function is loaded in FLASHA but run from PRAML0.

Regards,

Manoj

Manoj,

We have come across something suspicious.  We notice when executing the line(s):

  EALLOW;

  Flash_CallbackPtr = &MyCallbackFunction;

  EDIS;

The EMU_KEY and EMU_BOOT changes from 0x55AA and 0x000B to new values based on &MyCallbackFunction.  This seems very suspicious and we are digging in further.

We have in one of our linker command files:

MEMORY

{

PAGE 0:    /* Program Memory */

PAGE 1:    /* Data Memory */

 ...

      PIE_CTRL    : origin = 0x000CE0, length = 0x000020    

/* PIE Control Registers */

      PIE_VECT    : origin = 0x000D00, length = 0x000100    

/* PIE Vector Table */

 ...

}

　

SECTIONS

{

/*** PIE Vect Table and Boot ROM Variables Structures ***/

 

UNION run = PIE_VECT, PAGE = 1

   {

      PieVectTableFile

     

GROUP

      {

         EmuKeyVar

         EmuBModeVar

         FlashCallbackVar

         FlashScalingVar

      }

   }

...

if you have any suggestions or want more specific information, please let us know.

Thanks,

Stuart

Monaj,

Standby on spending too much effort on my last communication here... I may have found something promising...

Thanks,

Stuart

We have resolved the issue.  The project is based off of the MotorWare Instaspin Motion project examples.  As such, the MotorWare does not define access to the peripherals in the same way that the FLASH example does through a F2806x_GlobalVariableDefs.c.  As such, we selectively copied over the symbols definitions from this file into our project based on observed linker warnings.

Since EMU_KEY and EMU_BOOT are not explicitly referenced by our project, the linker never warned us about these not being defined.  Unfortunately, EmuKeyVar, EmuBModeVar, FlashCallbackVar, and FlashScalingVar are allocated sequentially in the linker command file "F2806x_Headers_nonBIOS.cmd", so since EmuKeyVar and EmuBModeVar are not present at link time, FlashCallbackVar and FlashScalingVar were both being bumped up in memory by 32-bits or two words.

The solution was to simply copy in F28-6x_GlobalVariableDefs.c into our project such that all the peripheral objects get defined and aligned correctly.

Thanks,

Stuart

Hi Stuart,

what was your solution of this problem?

I've nearly the same problem with the Flash_erase ROM Function.

Best Regards, Andreas.

/* At Every Time: USE this four variables together in your Code.
*
* Verify the Addresses:
* EmuKeyVar @ 0x0D00
* EmuBModeVar @ 0x0D01
* FlashCallbackVar @ 0x0D02
* FlashScalingVar @ 0x0D04
* according to TI:
* SPRUH18G Technical Reference Manual TMS320x2806x Piccolo
* 2.2.9 Bootloader Modes, page 205
* Table 2-3 PIE Vector SARAM Locations Used by the Boot ROM
*/

Andreas,

I'm a bit confused by your post.  I've clearly outlined my solution in my earlier post.

Thanks,

Stuart