• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 267 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.

LAUNCHXL2-TMS57012: About peripheral polling in lockstep

Yoshihiro Nakai
Prodigy 10 points

Part Number: LAUNCHXL2-TMS57012
Other Parts Discussed in Thread: TMS570LS1227

Currently, we are developing a platform using tms570ls1227ZWT, and for the evaluation, we are developing an application using LAUNCH XL2-TMS57012.
When updating the flash using the F021_API library, prefetch_abort occurs in the following code.

while (FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmBusy) {}

I am polling peripherals with a macro, but since this I / O changes asynchronously, if it changes between the access of the master CPU and the checker CPU, the execution result will change. It seems that this is causing prefetch_abort.
This problem is always present when bowling peripherals. Is there a way around this?

  • 0
    TI__Guru**** 199386 points

    Hi Yoshihiro-San,

    1. The interrupts are not disabled inside the flash APIs, can you try to disable the interrupts before calling flash APIs?

    2. The TMS570LS1227 has only one program flash bank (bank 0). Please copy the F021 flash related code to RAM and execute then from RAM. 

  • 0 in reply to QJ Wang
    TI__Guru**** 199386 points

    If you want to erase and program in the same bank as where the F021 Flash API code resides, you will need to copy the routines into RAM.

    Please refer to the example used in TI CAN bootloader

  • +1 in reply to QJ Wang
    Prodigy 10 points

    こんにちはQJ王

    ご連絡ありがとうございます。私は英語が苦手なので、Google翻訳を使っています。表情がおかしいとごめんなさい。

    F021フラッシュ関連のコードをRAMにコピーし、割り込みを無効にしてRAMから実行しています。

    Prefetch_abortは、Flashの消去後に常に発生するわけではありませんが、高い確率で発生します。次のコードを実行すると、異常が発生した場合にカウンターに数百が表示されます。（-1）ではありません。
    デバッガでトレースしても問題ありません。


    intカウント;

    count = 0;
    while（FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmBusy）{count ++; }
    count = -1;


    ロックステップの動作を考慮すると、マスターCPUとチェッカーCPUはそれぞれ2サイクルの差で周辺機器を参照して分岐先を決定するため、2サイクルの間にステータスが変化すると分岐先も異なります。
    この状態が検出され、prefetch_abortが発生したようです。

    FPGAをEMIFに接続して制御する予定ですが、共有メモリが非同期に変更されると、同様の問題が発生します。
    ロックステップを止める機能がないので、どう対処したらいいのかわかりません。


    よろしくお願いします、
    よしひろ

  • 0 in reply to Yoshihiro Nakai
    Prodigy 10 points

    Hello QJ King

    Thank you very much for contacting me. I'm not good at English, so I use Google Translate. I'm sorry if the expression is strange.

    He has already copied the F021 flash related code to RAM and is running it from RAM with interrupts disabled.

    Prefetch_abort does not always occur after Flash erasure, but it does occur with a high probability. If you run the following code, the counter will show hundreds in case of anomalies. It is not (-1).
    No problem occurs when tracing with the debugger.


    int count;

    count = 0;
    while（FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmBusy）{ count++; }
    count = -1;


    Considering the operation of lockstep, the master CPU and the checker CPU each refer to the peripheral with a difference of 2 cycles to determine the branch destination, so if the status changes during the 2 cycles, the branch destination will also be different.
    It seems that this condition is detected and causes prefetch_abort.

    I plan to connect and control the FPGA to EMIF, but if the shared memory changes asynchronously, it will cause similar problems.
    Since there is no function to stop lockstep, I do not know how to deal with it.

  • 0 in reply to Yoshihiro Nakai
    TI__Guru**** 199386 points

    Hi Yashihiro-san,

    I will develop a test case for you to try.