This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi
I’m stuck with an issue I can’t figure out.
I’m using the CRC module in semi CPU mode triggered by RTI.
The code written is largely inspired by SPNA235 and the corresponding example project.
RTI3 compare is set at 1us like in the example.
The CRC tables for my project is as follows:
_boot_crc_table @ 00043060 records: 9, size/record: 24, table size: 224
.intvecs: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000000, size=00000020, CRC=1f7dab46cae46a4b
flashAPI_Text: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00000020, size=00001cc0, CRC=681efbb03fd28603
.text: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00001ce0, size=0003c720, CRC=608adbf01af3ea34
.const: algorithm=TMS570_CRC64_ISO(ID=10), load addr=0003e400, size=00001ef8, CRC=41ace6b9b533be9b
FEE_TEXT_SECTION: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000402f8, size=00001df8, CRC=d33e7c3d359d84b8
flashAPI_Const: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000420f0, size=00000220, CRC=382cccd4e5d7e60b
FEE_CONST_SECTION: algorithm=TMS570_CRC64_ISO(ID=10), load addr=00042310, size=000001a0, CRC=0208a83974856964
.cinit: algorithm=TMS570_CRC64_ISO(ID=10), load addr=000424b0, size=00000bb0, CRC=033294923ac8e483
.boot_info_section: algorithm=TMS570_CRC64_ISO(ID=10), load addr=0005fff8, size=00000008, CRC=1b00001b00000000
SW works well for the first 2 sections e CRC calculates and comparison match. But CRC module watchdog times out on the 3rd section. Interrupt flags in CRC notification = 0x10.
The size of the section to calculate the CRC on is larger than in the example project. But I would expect still the CRC module to be able to handle that for large sections of memory.
Digging further the DMA transfer starts but stops PrtBChnSrcAddr == 0x1CF0.
Executing the code further, ESM kicks in with an undef entry exception.
ESMStat1 == 0x40, ESMStat2 = 0x00, ESMStat3 = 0x080.
It suggest an uncorrectble error has been encountered. I tried disabling ECC and initializing the flash bank 0 where the code is running.
Unsuccessl so far.
Could you please point me into the right direction about the cause this behaviour ?
I can share part of if it is useful.
1. Can you fill the holes with a value?
2. You can generate ECC using linker cmd for the whole flash.
http://software-dl.ti.com/hercules/hercules_docs/latest/hercules/How_to_Guides/index.html
I’ve been adapting my linker script to reflect the one of the example project.
MEMORY
{
VECTORS (X) : origin=BOOT_START_ADDRESS length=0x00000020 fill=0xFFFFFFFF
BOOTLOADERFLASH (RX) : origin=(end(VECTORS)) length=(0x0060000 - (BOOT_START_ADDRESS + size(VECTORS) + BOOT_INFO_SIZE)) vfill=0xFFFFFFFF // 384K
BOOTLINFO (RX) : origin=(start(BOOTLOADERFLASH)+size(BOOTLOADERFLASH)) length=BOOT_INFO_SIZE vfill=0xFFFFFFFF // 8Bytes
FLASH_NVM_SECT1 (RW) : origin=0xF0200000 length=0x4000 vfill=0xFFFFFFFF // 16K
FLASH_NVM_SECT2 (RW) : origin=0xF0204000 length=0x4000 vfill=0xFFFFFFFF // 16K
FLASH_NVM_SECT3 (RW) : origin=0xF0208000 length=0x4000 vfill=0xFFFFFFFF // 16K
FLASH_NVM_SECT4 (RW) : origin=0xF020C000 length=0x4000 vfill=0xFFFFFFFF // 16K vfill=0xFFFFFFFF //16K * 4 sectors
STACKS (RW) : origin=0x08000000 length=0x00001500 vfill=0xFFFFFFFF
RAM (RWX) : origin=0x08001500 length=0x0003EB00 vfill=0x0
ECC_VEC (R) : origin=(0xf0400000 + (BOOT_START_ADDRESS >> 3))
length=(0x00000020 >> 3)
ECC={ algorithm=algoL2R5F021, input_range=VECTORS, fill=false }
ECC_BOOTLOADERFLASH (R) : origin=(0xf0400000 + size(ECC_VEC)) // ECC BOOTLOADERFLASH include BOOTLINFO section
length=((0x0060000 - (BOOT_START_ADDRESS + size(VECTORS) + size(BOOTLINFO)))>> 3) // + BOOT_INFO_SIZE)) >> 3)
ECC={ algorithm=algoL2R5F021, input_range=BOOTLOADERFLASH, fill=false }
ECC_BOOTLINFO (R) : origin=(0xf0400000 + size(ECC_BOOTLOADERFLASH) + size(ECC_VEC))
length=(size(BOOTLINFO) >>3 )
ECC={ algorithm=algoL2R5F021, input_range=BOOTLINFO, fill=false }
…
}
But no success. Exactly same behaviour.
The DMA transfer stops at address 0xE380 after transferring 50848 bytes of data.
At 0xE380, there is no hole.
.text 0 00001ce0 0003c948
00001ce0 000058ec ti_fee_util.obj (.text)
000075cc 00002cdc sys_selftest.obj (.text)
0000a2a8 000025d4 CanTp_Prv.obj (.text)
0000c87c 00001e08 CanSM_InternalStateTransition.obj (.text)
0000e684 000017a8 ti_fee_ini.obj (.text)
0000fe2c 000014cc CanTp.obj (.text)
000112f8 0000139c Ios_Std.obj (.text)
I did not see a limitation on any size of DMA transfer….
I’m stuck with this but this working being quite key for a robust and performant bootloader.
On your side did you try to the project I shared with you ? Can you reproduce the problem ?
Regards
Seb