TM4C129XNCZAD: Invalid execution sequence

Ralph Jacobi said:

I wish that were an option, but the simulation database for these devices is in archive.

I was able to get the same hard fault by porting the example run on a MSP-EXP432E401Y.

The main source file just required the following changes to port from TivaWare to simplelink_msp432e4_sdk_4_20_00_12:

• Change to include files; include ti/devices/msp432e4/driverlib/driverlib.h rather than the individual include files for TivaWare
• Change the name of the interrupt functions to match those in the ccs/startup_msp432e401y_ccs.c file; the MSP432E4 simplelink start up files defines ISRs with a weak alias which means can use ISR function names without having to modify interruptVectors[] array

At first the ported example didn't fail, but was able to get it to fail by adding the following in the linker command file to adjust the addresses of the functions in flash:

    padded_sect:
    {
        /* Forcing this 2 byte padding make the hard fault occur */
        . += 2;

        MSP432E401Y_systick_wfi_main.obj(.text)
    }  > FLASH

This is not that surprising, as the failure more seems sensitive to instruction alignment and the MSP432E driverlib and startup functions maybe different to the TivaWare versions.

Since the MSP432E401Y is a newer part, which uses the same peripherals as the TM4C129 series, perhaps the MSP432 team are able to run a device simulation with the attached example?

MSP432E401Y_systick_wfi.zip

Hi Chester,

Ralph is out this week. He has better contacts with the MSP group than I, so I will let him answer for sure when he gets back. However, I am afraid they will have the same limitations as we do.

Hello Chester,

I am not sure what capability they have to do so. My contacts are more on the application side, not on the design side. Also, even if they do, to ask them to spend such resources to do such an investigation on a TM4C issue is not trivial to do given their own priorities and I don't have the ability to make that request at this time.

Hello Ralph & Chester,

First of all I wish you a happy new year despite these complicated times we are going through.

To give you some update on our side, we did some tests using the DSB and ISB instruction before and after the WFI instruction, the problem is still present.

@Ralph Do you have any update on the subject? Using a FPGA emulator they might have used when designing the MCU might indeed be a good solution study further the issue as Chester stated.

Best regards,

Matthieu Tardivon

Hello Matthieu,

We don't have any other updates on our end unfortunately. Were you able to test if turning off prefetch buffers at least works reliably to solve it? We could try and hone in on that specifically if its confirmed that is a 100% fix though the idea of the memory alignment was really targeted towards that idea...

Matthieu Tardivon said:

@Ralph Do you have any update on the subject? Using a FPGA emulator they might have used when designing the MCU might indeed be a good solution study further the issue as Chester stated.

Unfortunately, I don't have the capability to make a request for another engineering team to look into something this complex. Such a cross-product investigation occurs very rarely. If you have a TI field sales contact, perhaps talk with them and see what they could do to help with pushing through such a request?

I was wondering if could investigate the prefetch buffers by modifying the program to have the main and interrupt functions running in RAM, and reading test patterns from flash to see if could show incorrect data read from flash after a wakeup from sleep.

By having the functions in RAM could allow the symptoms to be investigated without having more obscure crashes; caused by say having the flash prefetch buffers supply invalid instructions to the Cortex-M3.

Haven't yet attempted this.