Part Number: TMS320F28388D
Other Parts Discussed in Thread: UNIFLASH, , C2000WARE
Hello,
I have been working with the flash API since a long time and it has been working great all along until now. I have been working with the flash API in a synchronous manner, using the Fapi_issueProgrammingCommand() function always followed by a while(Fapi_checkFsmForReady() != Fapi_Status_FsmReady). In order to make my flash access less time consuming, I have decided to separate the calls to Fapi_issueProgrammingCommand() and the check that the Flash Memory Controller is ready for the next command so I can issue a programming command and then poll the FMC until it's ready to receive a new command in a non blocking way. And it has been also working great until my program ran through a path that writes many data in flash in which I forgot to add the new function checking for the readyness of the flash api for a new command. At this point I basically did a for loop in which there is essentially Fapi_issueProgrammingCommand() functions and of course no while(Fapi_checkFsmForReady() != Fapi_Status_FsmReady). That would look like this:
for ( i=0; i<200;i++) {
Fapi_StatusType apiResult = Fapi_issueProgrammingCommand(
(uint32_t *)address, FLASH_AlignedBuffer, 4, 0, 0, Fapi_AutoEccGeneration);
}
My program was running on core1 with all functions loaded in RAM during initialization. So for now, the program still runs but all the flash access are denied. The program is not writing to the flash anymore and I can not program my core1 either. I tried the operation on 2 TMS320F28388D. on the first one, I just lost access to every flash control you can think of either through UniFlash or CCS. But I can still connect via JTAG (run the code step by step for exemple) but I can't erase the flash nor reprogram it even though I can still read it. I have checked everything I could think of: trying to unlock the DCSM but it seems it is not locked, using the erase function of CCS On-Chip flash, using the erase function of UniFlash. When I try to upload code, I have these outputs from the GEL file:
C28xx_CPU1: Error initializing flash programming: Interface returned from dll, but flash is not available on this device.
C28xx_CPU1: GEL Output: ... DCSM Initialization Start ... C28xx_CPU1: GEL Output: ... DCSM Initialization Done ... C28xx_CPU1: GEL Output: CPU2 is out of reset and configured to wait boot. (If you connected previously, may have to resume CPU2 to reach wait boot loop.) C28xx_CPU1: GEL Output: CM is out of reset and configured to wait boot. (If you connected previously, may have to resume CM to reach wait boot loop.) C28xx_CPU1: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map. C28xx_CPU1: Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0x18368: (Error -1066 @ 0x18368) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 9.2.0.00002)
And any operations in the CCS On-Chip Flash utility results in a pop up informing me that : "Target is not connected or does not support current Flash operation" whereas I am connected via JTAG and running the code step by step. Another interesting thing is that the code does not run when I am not connected via JTAG. The thing is, to run my code in debug mode, I have to run the "emu boot Flash" script. When I power up my microcontroller, it is not able to boot by itself anymore. The core2 is still fully functionnal, I can load code into it and everything runs fine.
On the 2nd TMS320F28388D, after running the bad code, it seemed all right so i just unplugged the jtag connection. Since that moment, it is impossible to connect to that microcontroller, the code does not run (probably the same booting problem as the other one) but I can't even connect to any of the two core in jtag anymore.
I am running out of ideas but I need to get these two microcontrollers back to work so any hint would be greatly appreciated.
Best regards,
Quentin
