TMS570LC4357-EP: Change the SCI interrupt mode to FIQ, and copy the FIQ and IRQ vector tables to SRAM.

Hi Shuo,

I will verify your code,

In mean time could you please verify below thread once, here i explained and shared an example for code execution in another bank (e.g. Bank-7):

(+) TMS570LS1227: Using TMS570LS1227 Flash BANK7 for Dataload Software - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards,
Jagadish.

Hi gundavarapu,

I’d like to add some more information I’ve recently discovered.

1. Program for Jumping to Address 0

resetEntry
        bl   _mpuInit_
        mov r0, #0x0000       ; low 16-bit
		movt r0, #0x0008       ; High 16-bit
        bx	r0
undefEntry
        b   undefEntry
svcEntry
        b   svcEntry
prefetchEntry
        b   prefetchEntry
dataEntry
        b   dataEntry

2. The app is located in sector 0. Case where an app verifies that a serial port interrupt is an IRQ

2.1 Call the functions _coreEnableIrqVicOffset_(); and _enable_IRQ_interrupt_();

The serial port is functioning normally at this point, but debugging reveals that the program does not execute up to the `irqEntry` point.

2.2 Call only the _enable_IRQ_interrupt_(); function; do not call _coreEnableIrqVicOffset_();

The serial port is functioning normally at this point, and debugging reveals that the program frequently executes up to the `irqEntry` point.

3. The app is located in sector 0. Case where an app verifies that a serial port interrupt is an FIQ

Since the _coreEnableFiqVicOffset_(); function is missing, only the _enable_interrupt_(); function is called. At this point, the serial port is functioning normally, but debugging reveals that the program frequently executes up to the FiqEntry point.

4. The app is located in sector 10. Case where an app verifies that a serial port interrupt is an IRQ

4.1 Call the functions _coreEnableIrqVicOffset_(); and _enable_IRQ_interrupt_();

At this point, the serial port is functioning normally.

4.2Do not call the function _coreEnableIrqVicOffset_(); call only the function _enable_IRQ_interrupt_()

At this point, the serial port is not functioning properly.

5. The app is located in sector 10. Case where an app verifies that a serial port interrupt is an FIQ

At this point, simply calling the _enable_interrupt_(); function will cause the program to crash.

6. Conclusion

6.1 The serial port, configured as an IRQ, works normally in sector 10 because when the interrupt occurs, the program does not jump to 0x00000018 when calling the _coreEnableIrqVicOffset_(); function. I would like to ask what the purpose of this function is.

6.2 The interrupt mode set to FIQ for the serial port does not function properly in sector 10 because, when the FIQ interrupt is enabled, the program jumps to address 0x0000001C, which is empty, causing an exception.

The following describes the testing process and observed phenomena when I loaded the vector table into SRAM.

1. define sect

2. link file

3. copy

4. Debugging Issues

When an interrupt occurs, it still jumps to 0x0000001C. Am I missing something?

Hi Shuo,

Apologies for the delayed response!

I understood the root cause for the issue!

Here is explanation:

• The exception vector table on TMS570 Hercules devices is fixed at address 0x00000000
• Unlike Cortex-M3/M4 (which have VTABLE register for relocation), Cortex-R4/R5 does not provide hardware-based vector table relocation

So, when your linker cmd file is as below:

As you can see there is no proper vector table at address 0x00000000, but if controller got reset the core will always expect the vector table to be at 0x00000000. That is why it is crashing.

You can do below method to avoid this problem:

As shown above just try to keep vector table at starting of the flash and you can keep remaining code wherever you want that doesn't matter. So, only vector table (0x40 size in your case should need to be at starting of the flash). Now you can see there are valid jump instructions at starting of the flash right, so whenever warm reset or POR reset happens the core will jump properly to the init function and performs the execution properly without any crash.

I tested at my end after above modification and it is working fine without any issues; here is the code for the same for your reference:

TMS_09_GNSS_SCI_FIQ_TEST.zip

Here are the test results after above suggested modification:

--
Thanks & regards,
Jagadish.

Hi, gundavarapu

I see what you mean.

In fact, I placed the loader at address 0 and configured the fiqEntry, so even though the app's vector is defined at 0x00080000, the program still works fine.

The loader is shown below:

However, I plan to implement only basic jump functionality at address 0, as shown below:

The loader is stored in the OTP, and the app is stored in another sector. I want the OTP program and the app to share the vector table. How can I achieve this? This must be done without changing the program at address 0.

The post I referenced should have been implemented, but I think I may have missed something.

Hi Shuo,

shuo liu said:

The loader is stored in the OTP, and the app is stored in another sector. I want the OTP program and the app to share the vector table. How can I achieve this?

As per my understanding, you no need to do anything separately to share vector table they will share anyway.

I mean for example if any data_abort occurs on either bootloader or application then the code will jump to the below location of the exception table:

Same thing applicable for other exception entries as well. So just perform your testing by keeping exception vector table at 0x0 and let me know if you have any further issues.

--
Thanks & regards,
Jagadish.