• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 742 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.

Problem with F021 library and emulated EEPROM

Richard Burke
Expert 1910 points
Other Parts Discussed in Thread: TMS570LS3137

Hello,

In a previous post (http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/197625/754475.aspx#754475) I was having problems with the F021 flash library on a TMS570LS3137. This problem was resolved by placing functions in RAM.

I now have another problem with bank 7 (emulated EEPROM). I have set up a test program that continuously erases and then programs each 16K segment. If I run the program in the CCS debugger and put a break before and after each erase it works every time. However if I remove the breakpoints and then run, the program seems to crash and CCS reports the following:
Error connecting to the target:
Error 0x80001A20/-2062
Fatal Error during: Execution, OCS, Timeout, Target,
Cannot halt the processor

I have tried relocating the write and erase functions to RAM to no effect. We have interrupts enabled including FIQ interrupts.

Do you have any suggestions?

Regards,
Richard

  • 0
    TI__Mastermind 22715 points

    Richard,

    You should be able to erase/program EEPROM bank while your code runs from main bank with interrupts enabled. I would suggest first removing the EEPROM bank erase/program functions to see if the problem is caused by other functions in your application. Then you can add I/O pin toggling before and after EEPROM bank erase /program to see if those function completes correctly without using debugger. We can help you looking into more details after these initial steps.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    Expert 1910 points

    Hi Zhaohong,

    Sometimes low tech is the solution! The LEDs helped me to highlight the issue.

    Thanks,
    Richard

  • 0 in reply to Richard Burke
    Expert 1910 points

    Hi Zhaohong,

    My colleagues have told me I can't just leave this one hanging! The problem was caused by a programming error where a state variable should have been declared static and wasn't but it has raised a legitimate concern.

    The end result of the coding error was that I was calling Fapi_issueProgrammingCommand to write a page of memory before Fapi_issueAsyncCommandWithAddress (to erase a sector) had finished. The result was a fairly spectacular locking up of the chip including the JTAG interface. In the interests of defensive programming shouldn't the F021 library check that the flash engine is not busy following a previous operation before allowing a program or erase operation?

    Regards,
    Richard

  • 0 in reply to Richard Burke
    TI__Mastermind 22715 points

    Richard,

    You have to call the'Fapi_checkFsmForReady()" function to check the status. You can use the following sequence as a reference.


        Fapi_initializeAPI((Fapi_FmcRegistersType *)0xfff87000,Freq_In_MHz);

        Fapi_setActiveFlashBank(7); //enable EEPROM bank

        Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32 *)Flash_Start_Address); //erase a sector

        while( Fapi_checkFsmForReady() == Fapi_Status_FsmBusy ); //wait for erase to complete

        while( bytes_remain > 0)
        {
            Fapi_issueProgrammingCommand((unsigned int *)dst,
                                         (unsigned char *)src,
                                         (unsigned long) 16,
                                         0,
                                         0,
                                         Fapi_AutoEccGeneration);

             while( Fapi_checkFsmForReady() == Fapi_Status_FsmBusy );

            src += 0x10;
            dst += 0x10;
            bytes_remain -= 0x10;
        }

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    Expert 1910 points

    Hi Zhaohong,

    When using the memory as emulated EEPROM we don't want to hang around waiting whilst it is busy, hence the use of a state machine. The mistake I made was to omit the "while busy" part. My query now is whether the call to Fapi_issueProgrammingCommand should detect that the erase cycle or a previous write is still busy and return an error rather than just locking up the processor which is what appears to happen now.

    Regards,
    Richard

  • 0 in reply to Richard Burke
    TI__Mastermind 22715 points

    Richard,

    You have to call Fapi_checkFsmForReady() to make sure that FSM is not busy before calling Fapi_issueProgrammingCommand(). I personally prefer this sequence. It provide a clear view of the process. To me, putting Fapi_checkFsmForReady() inside Fapi_issueProgrammingCommand() is only a programming style change. If you really like this style, you can put together a wrapper function which includes those two API calls.

    Thanks and regards,

    Zhaohong