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.

TM4C129 configure the stall count for EPI HB16 iRDY

Other Parts Discussed in Thread: TM4C129XNCZAD, LMFLASHPROGRAMMER

Hi,

I would like to know if its possible to limit the stall count of the EPI HB16 to a few clock cycles if iRDY is not asserted.

Currently, it seems like the Cortex is waiting indefinitely for the iRDY signal and thus locking up CPU.

In my case this means a complete system failure if one of the chips attached to the Cortex/EPI interface fails.

The EPIConfigHB16TimingSet doesn't do the job

    EPIConfigHB16TimingSet(EPI0_BASE,
                        EPI_HB16_IN_READY_DELAY_1            |        //sets the stall on input ready (EPIS032)
                                                                                                         //to start 1 EPI clock after signaled
                        EPI_HB16_WRWAIT_MINUS_ENABLE  |        //enables a 1 EPI clock write wait state reduction
                        EPI_HB16_RDWAIT_MINUS_ENABLE);         //enables a 1 EPI clock read wait state reduction

Khaled.

  • Hello Khaled,

    Is the EPICLK enabled in the configuration? Please when putting a debug post, do include the configuration of the peripheral as it helps set up the peripheral on test board.

    Regards
    Amit
  • Sorry about that. It was more of a general HB16 configuration question. I"m attaching for the configuration file.

    Khaled.

    EpiHb16Config.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    int main(void) {
    //desired system frequency
    gSysCtlClock = SysCtlClockFreqSet(
    SYSCTL_USE_PLL |
    SYSCTL_OSC_MAIN |
    SYSCTL_XTAL_25MHZ |
    SYSCTL_CFG_VCO_480,
    120000000);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_EPI0);
    SysCtlPeripheralReset(SYSCTL_PERIPH_EPI0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOA);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOB);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOC);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOD);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOF);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOG);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOH);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOJ);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOJ);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOK);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOL);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOL);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOM);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOM);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPION);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOP);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOQ);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOR);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOR);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOS);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOS);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOT);
    SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOT);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello Khaled,

    What is the value of the define EPI_DIV_FACTOR_DATA?

    Regards
    Amit
  • #define EPI_DIV_FACTOR_DATA 1

    Khaled.

  • Hello Khaled

    I ran the code on a TM4C129XNCZAD device and the code never stalls irrespective of EPI0S32 (iRDY) being High or Low. The while loop always executes.

    Regards
    Amit
  • Hi Amit,
    Its definitely stalling for me. I spend more than a week trying to find the reason. Not only the Cortex stalled, but I lost access to it as well (check silver.arm.com/.../preload.tsh for the problem that I had).
    Khaled.
  • Hello Khaled,

    The link is not accessible in TI network. Please upload the files in the forum post using "Use rich formatting" link on the bottom right of the reply window. Also specify the tool to use to view the file.

    From your IDE, please take a snapshot of EPI registers so that I can confirm the settings as well.

    Regards
    Amit
  • Here is a copy of the initial message and how it was resolved


    //------------------------------------ message 1 start ----------------------

    Hi,

    I can't erase the cortex M4 anymore. I'm using keil uVision Version 5.15.0 and RTX for bios.

    I have two TM4C129XNCZAD boards. They used to work fine (erase, program and run) until I changed my program (not sure what I have changed) but from that point on, I'm not able to erase the Cortex and I keep getting the following message:

    " Could not stop Cortex-M device! Please check the JTAG cable"

    I tried reducing the JTAG clock, no success.

    I tried to switch from SW, to JTAG, to SW/SWJ... non worked.

    I tried to connect through the USB debugger port (ICDI) still no success.

    What else can I try.

    Khaled.

    //------------------------------------ message 2 start ----------------------

    These suggestions are taken from the device's datasheet:
    www.ti.com/.../tm4c129xnczad.pdf
    
    Pg. 225 describes one way to recover a 'locked' microcontroller, if the JTAG/SWD pins were also configured as GPIO pins, by accident. 
    Try these steps. Even if this did not specifically occur, it will still cause a mass erase, which should allow the device to be reprogrammed.
    
    Pg. 257 describes the Hardware System Service Request (HSSR). This could be another way to trigger a mass erase, 
    try the steps using _WWORD in the Command Window, if the System Viewer does not provide a way to complete the instructions from SYSCTL => RESC => ...HSSR.
    
    Pg. 646 also describes another (probably easier) way to perform a mass erase.
    
    Let us know if we can be of further assistance. 
    Erasing the device would at least allow you to program it once more before 
    receiving the "Could not stop Cortex-M device" message, to troubleshoot the cause of the message.
    
    Thanks,
    Zack

    //------------------------------------ message 3 start ----------------------

    Zack
    thank you for the additional info.
    I tried the first approach by switching between JATG and SW using the Keil/uvision/Flash/Debug/setting/Port with no success. I think that I'm doing it wrong.
    I was not able to try the second and third approach. I don't know how to write to the different registers while the Cortex is down.
    
    Do you have a program/executable that I can install that could apply those sequences for me?
    thanks.
    Khaled.

    //------------------------------------ message 4 start ----------------------


    Hello Khaled,
    The process described on Pg. 225 is your best option, then. I think switching the ports in the Target Driver Setup for the ULINK2 would complete all the steps (1-3), when the instructions only want you to complete Steps 1 and 2.
    There might be an automated way to do this, with LM Flash programmer/utility: www.ti.com/.../lmflashprogrammer Download and install the software, if you do not already have it on your computer. Go to Configuration tab => Select the appropriate interface. Then go to Other Utilities tab => Debug Port Unlock => Select the option that includes the TM4C129 class. Then click "Unlock".
    Otherwise, you should find another utility that will allow this group and timing of sequences or write the code to use a serial cable to send these signals (Visual Studio has some pre-built methods to help accomplish this) to the SW/JTAG interface. It would be worth the effort to automate this, because even if you recovered a device, you would want to be able to debug why the SW/JTAG interface was disrupted in the first place, and to quickly unlock the device if the issue reoccurs.
    Our tools lack a solution for this type of problem, so I am sorry, but you will have to find some other way to unlock the device, which we cannot really support. In this case, we can only point to where you may find answers.
    Good luck! Regards, Zack

    //------------------------------------ message 5 start ----------------------

    Hi Zack
    using the lm flash programmer did the trick :-)
    thanks.
    Khaled.

    //------------------------------------ message end ----------------------

    Here is a copy of the EPI registers. Hope its what you are asking for.

    Khaled.

  • Hi Amit,

    It seems the snap shot of the registers were not uploaded.

    Here they are again.

    Khaled.

  • Hello Khaled

    Attached is the snapshot of the code when I ran it on my side. What is different is that the EPI HB16CFG register on my setup shows a value of 0x0008.0101 while the same on your setup shows 0x0000.0001

    Regards

    Amit

  • Hello Amit,
    EPI_HB16CFG register set to 0x0008.0101 value is for iRDY disabled. You have to set it to 0x1008.0101 to enabled it.

    Correction to my previous e-mail, my EPI_HB16CFG register was set to 0x10080101 (uVision interface was displaying the wrong value but the memory display was correct).

    This is said my problem is not resolved. When iRDY bit is enabled, and the iRDY pin is asserted low, everything works fine. When iRDY pin is de-asserted high, I loose control over the Cortex (can't use break points in the debugger, and I cant erase the Flash anymore). Only if I re-assert iRDY low or if I use Lm Flash Programmer that I can have access to the Cortex again.

    Khaled.
  • Hello Khaled,

    The code file had the READY Enable commented.

    EPIConfigHB16Set( EPI0_BASE,
    // EPI_HB16_IN_READY_EN | //IRDY enabled
    EPI_HB16_MODE_ADDEMUX | //sets up data and address as separate

    When IRDY is enabled and the level matches the active level then the CPU bus will be stalled till the same is not resolved. That is why the debug connect is not possible and you have to use LMFlashProgrammer to unlock the device using JTAG Mass erase. Th iRDY is a stall function which must be resolved by the external device.

    Regards
    Amit
  • Amit,

    I commented out the iRDY enable command on purpose to get my testing going.

    I more or less reached the same conclusion as you: the external device has to assert high the iRDY in order for the Cortex not to stall indefinitely.

    My original question still stands: is there is a way to configure the Cortex/Epi interface/iRDY NOT TO STALL the cortex indefinitely?

    In my case, if the external device do not assert the iRDY signal, the Cortex dies as well and the entire system is lost!

    Khaled.

  • Hello Khaleed,

    No it is not possible. The reason is as follows

    1. The iRDY from the external device during a read or write is method to stall the TM4C device so that the next data operation is not performed till the external device has not released the bus.
    2. If there is a TIMEOUT, then what will happen is while the CPU gets an interrupt for the TIMEOUT, it may be possible that the device performs the next operation which is not valid as the external device is unresponsive to the last command. In case of read it may be the wrong data that can lead to another issue of incorrect data or control parameters being executed.

    Regards
    Amit
  • Thanks Amit,
    This is a set back. Assuming that the external device stopped responding, even if the watchdog kick in and resets the Cortex, on the next EPI read/write cycle, the Cortex will stall again.
    That is why I wanted a program the stall time. It should be up to the program developer to decide how to manage it (either wait indefinitely or wait a few clock cycles).
    You might want to add that to the next revision of the Cortex
    Thanks.
    Khaled.
  • Hello Khaled,

    The watchdog can still be used. When the TM4C device gets a reset due to a stall, it must not configure the EPI first. It should always configure the IO in GPIO input mode, read the state of the line, before making a decision to configure and use EPI.

    Regards
    Amit
  • Will do.

    thanks Amit.

    Khaled.

  • Hello Khaled,

    I did check the design and even when the GPIO is configured to be in EPI mode, the IO can still be read via the GPIO Data Register to know the state. So the IO configuration may still be performed in EPI mode to know if the Slave device is stuck or not,

    Regards
    Amit
  • Hi Amit,
    Yes, the most of the IO could be checked to see if they are stuck.
    The iRDY test is more difficult: iRDY is de-asserted low by default i.e. its not ready. Only after a read or write attempt the iRDY will be asserted high by the external device if its ready to be read or written.

    This means that we have to perform a read or write first and if we do so, the Cortex will get stuck.
    There is really no way around it except to program the stall count to something less than infinity.
    Khaled.
  • Hello Khaled,

    I would contest the fact that iRDY should be deasserted in the beginning. It must be left floating and a pull up must be used to indicate to the Master side that it is ready for a transaction. When a valid access is started, can the iRDY be driven low and then driven high to indicate completion of the transaction. Once the CS deasserts so does the iRDY.

    In case of a failed transaction, the iRDY may remain stuck to low allowing the master to detect a failing slave device.

    Regards
    Amit