• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 474 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS570 Cortex-R5F Core - All Fatal bus error events

TMS570LC4357: ESM high interrupt was triggered twice after powering up

dai dai
Prodigy 60 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

After powering up and enabling FIRQ, the ESM high-priority interrupt is immediately triggered. 

After a while, when FreeRTOS starts scheduling, the interrupt is triggered again. After that, the program seems to run normally, and the fault no longer occurs.

Both times the fault occurred, esmREG-> IOFFHR = 36.

I checked the corresponding manual, and it appears that this fault is related to Cortex-R5F Core - All fatal bus error events. [Commonly caused by improper or incomplete ECC values in Flash.]

I found a similar issue in another thread. The solution seems to be using vfill to fill the entire flash.

However,we add some data to the file after CCS generates the hex, which seems to make it difficult to ensure ECC correctness. Also, I’m not sure if this is the reason for the interrupts. Sometimes, after burning an additional application, the interrupts don’t seem to occur

  • 0
    TI__Guru 69771 points

    Hi Dai,

    dai dai said:
    However,we add some data to the file after CCS generates the hex, which seems to make it difficult to ensure ECC correctness. Also, I’m not sure if this is the reason for the interrupts. Sometimes, after burning an additional application, the interrupts don’t seem to occur

    I think the additional adding data might cause the issue, because the CCS will generate the ECC automatically for the application if we enable the below option.

    But how you are adding the additional data to the CCS generated Hex file? are you adding ECC to the corresponding data at ECC section?

    If we didn't add ECC to the corresponding data then it might cause the problem, because the ECC checking will always be in enabled state for this device. So, it will do speculative fetches and verify the integrity in the flash contents, if there is any ECC errors then the device will generate the ESM errors.

    My suggestion would be first remove the additional data you are adding and verify the ESM error, if the error not occurring after removing this data, then it should be with the data only. And then we will verify the process of programming this additional data.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 60 points

    Hi jagadish,

    thank you for response

    1.We use Uniflash or the MCU with the F021 library for programming.As shown in the image below, I should have enabled the ECC-related settings.

    2. We use our own tool to parse the hex file generated by CCS and add the data we want at the corresponding locations. I was wondering if the ECC could also be added during the programming process?

    3.I tried not adding extra data and added vfill in the cmd file, but I found that vfill doesn't seem to fill the gaps in the flash, and the issue still persists. Below are the section allocations in our cmd file and the actual generated hex file.

    hex

    cmd

    starts at address 0x10 0000 with the vector table, with a region size of 0x100. The kernel data starts at 0x10 0100, but the actual generated file seems to have a gap between the vector table and the kernel data.

    4.last question,if we fill the flash this way, the programming file will be quite large, which could result in longer software programming times.

  • 0 in reply to dai dai
    TI__Guru 69771 points

    Hi Dai,

    dai dai said:
    1.We use Uniflash or the MCU with the F021 library for programming.As shown in the image below, I should have enabled the ECC-related settings.

    This looks fine for me.

    dai dai said:
    2. We use our own tool to parse the hex file generated by CCS and add the data we want at the corresponding locations. I was wondering if the ECC could also be added during the programming process?

    If you are programming like you mentioned in step-1 processes, then at parsing level you no need to add ECC i guess.

    dai dai said:
    3.I tried not adding extra data and added vfill in the cmd file, but I found that vfill doesn't seem to fill the gaps in the flash, and the issue still persists. Below are the section allocations in our cmd file and the actual generated hex file.

    Is it possible to share one simplest project with the issue, so that i can debug and can see the issue lively on my end as well.

    dai dai said:
    4.last question,if we fill the flash this way, the programming file will be quite large, which could result in longer software programming times.

    You are correct, code size will be increased, and software programming will take time.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 60 points

    Hi jagadish,

    Today I continued testing this issue and made some new discoveries:

    1. When using vfill for debugging, as soon as coreEnableEventBusExport is executed, esm SR2 immediately changes to 8. If it is changed to fill, and hex is filled, the esm high interrupt will only be triggered when the program accesses an address outside the hex range.
    2. Our program is split into two segments: one stored at 0x0 (boot) and the other at 0x100000 (app). Both are compiled separately via CCS. The program at address 0 checks the status of address 0x100000 to determine whether to launch another program. However, based on the above test results, when only the boot is present in flash, accessing the app address from the boot program triggers  interrupt. How can this be avoided?
    3. Additionally, during simulation debugging, I found that after a fault is triggered, I call esminit from the HAL library to initialize the fault, and sometimes the fault clears after the setup, but other times it has no effect. Why is that

  • 0 in reply to jagadish gundavarapu
    Prodigy 60 points

    I have another question. Currently, I can see that esmREG->IOFFHR = 36 and esmREG->SR1[1] = 8. Is there any way to further investigate this issue? Is there more detailed information available regarding Cortex-R5F Core - All fatal bus error events?"

  • 0 in reply to dai dai
    TI__Guru 69771 points

    Hi Dai,

    Is it possible to setup one live debugging session for this issue, this will helpful to understand issue more clearly and can provide my suggestions based on that.

    I will be available from 10AM to 8PM IST (Indian Standard Time), so based on your availability setup a meeting one day before.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 60 points

    Hi jagadish,

    1.I don't know how to handle this live debugging session.Is there a corresponding guide or documentation available?

    2.The issue I'm encountering is that when the program accesses addresses outside the programmed range, it triggers an esm fault (Cortex-R5F Core - All fatal bus error events.). For example, if my programmed range is from 0x0000 0000 to 0x0010 0000, and after programming this hex file into the chip, read the flash address 0x0020 0000 triggers an interrupt. At this point, if I program the address 0x0020 0000 with new data, accessing this address will no longer cause a fault. I want to know if it's possible to ensure that accessing flash addresses does not trigger the ESM interrupt even when the program is not being reprogrammed

  • +1 in reply to dai dai
    TI__Guru 69771 points

    Hi Dai,

    dai dai said:
    1.I don't know how to handle this live debugging session.Is there a corresponding guide or documentation available?

    It is simple, you just need to share your screen and explain me the issue in live. That would be helpful to understand issue more clearly.

    dai dai said:
    2.The issue I'm encountering is that when the program accesses addresses outside the programmed range, it triggers an esm fault (Cortex-R5F Core - All fatal bus error events.). For example, if my programmed range is from 0x0000 0000 to 0x0010 0000, and after programming this hex file into the chip, read the flash address 0x0020 0000 triggers an interrupt. At this point, if I program the address 0x0020 0000 with new data, accessing this address will no longer cause a fault. I want to know if it's possible to ensure that accessing flash addresses does not trigger the ESM interrupt even when the program is not being reprogrammed

    Why are you trying to access the outside the programmed memory?

    It might be possible to get ESM interrupt if you access the outside the programmed range, because this area might not have valid ECC for the data. So, accessing this area will trigger ECC errors and they can lead to ESM interrupts.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 60 points

    Because we have divided the flash addresses to store multiple programs, such as the bootloader and multiple apps, the bootloader will verify whether the corresponding flash address of the app contains a valid app before jumping to the app. This action will trigger an ESM interrupt if no program has been burned into the app region

  • 0 in reply to dai dai
    TI__Guru 69771 points

    Hi Dai,

    Apologies for the delay in late response.

    dai dai said:
    This action will trigger an ESM interrupt if no program has been burned into the app region

    You are right, this action can lead to the ESM interrupt.

    To avoid this, we should program the entire flash with valid ECC. I mean for the data 0xFFFFFFFF locations should also consists of valid ECC. If that happens then accessing outside the app region may not give ECC errors. To do this we have to fill the unused flash with 0xFFFFFFFF using either fill or vfill in the linker cmd files.

    --
    Thanks & regards,
    Jagadish.