- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hello,
I could use some hints, ideas, suggestions. I'm writing a bootloader, that resides in the first flash sector and should accept a firmware over CAN and store it in the remaining sectors. The bootloader erases the flash sectors that are reserved for the firmware and then flashed the firmware with data coming from the CAN bus. This works quite well!
I build the software, using make (CMake) and load the resulting bootloader.out file with CSS and a XDS200 into the TMS320F28379Ds first CPU (all other CPUs are idle). I start the software and everything works fine.
When I now power down the hardware and power it up again, the software crashed with an illegal operation. So far, it seems that the crash steams from the returning of the function that contains calls to the F021 API (which resides in RAM). If I comment out the calls to the F021 API functions, the bootloader does not crash. When I single step through the code, the API calls are not crashing, but the returning from the RAM resided calling function back to the function in flash seems to be the problem. (Function is busy waiting for Fapi_checkFsmForReady() to return Fapi_Status_FsmReady).
To me it looks like, the loading of the bootloader.out file does have some required side effects that does not take place, when power reseting the software. I've tried to set a Range Avoidance Settings: 0x00-0x80000, 0x82000-0xffffffff to prevent the debug probe (XDS200) from writing to anything else beside the flash sector of the bootloader. But this doesn't changed anything.
Is there something, I could use to see the memory range the debug probe is writing to?
best regards,
Torsten
1) No. I debugged the situation multiple times now. Wenn debugging on source level, I receive the ITRAP when returning from the function above. If I try to return from that function on assembler code level, I do not experience an ITRAP. Either it's a Heisenbug or it's related to timings. I tried to debug through the assembler code quite fast, but I'm not able to cause the ITRAP, when debugging in assembler (Assembler Step Into).
2) Yes.
3) 0x00081ce2 and 0x000087ba
4) Watchdog is disabled.
5) I don't think so. Please find attached a screenshot of the FLASH_ECC_REGS Registers
6) I observed that only once. And I've never observed it again. From the intended program flow, it would not be expected. But if I would observe that reproducible, it would probably be the culprit I'm looking for. I guess it was a glitch in CCS.
I made an other observation: The flashing fails due to the flash not being erased. The bootloader should have erased the flash. It does so, by calling the following function for all sectors of the firmware flash range:
RAMFUNC bool erase_sector(uint32_t start_address)
{
bool result = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,(uint32*)start_address) == Fapi_Status_Success;
while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady)
;
Fapi_FlashStatusType status = Fapi_getFsmStatus();
result = result && status == 0;
return result;
}
The function is called and does _not_ report an error (Fapi_getFsmStatus() returns 0). But it does _not_ erase the given sector! And _again_ this only happens, when the bootloader runs from POR. If the bootloader runs after loading the bootloader.out file into the target, everything went fine.
Is there a chance that I could get the source code of the F021 library?
Is there something else to initialize the F021 library beside calls to Fapi_initializeAPI() and Fapi_setActiveFlashBank()?
Any other idea in what direction, I could investigate?
best regards,
Torsten
