• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 84 subscribers
  • Views 421 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

LAUNCHXL-F280049C: CLA2 type GPIO toggle in task of ISR

LAUNCHXL-F280049C: Flash application copy to SRAM, SCIB ISR debug faults illegal instruction

Genatco
Guru 55603 points
Part Number: LAUNCHXL-F280049C

Hello,

Have separate #pragma statements above functions to copy Flash code sections into SRAM memory.

Verified each #pragma function was copied to same LSx location via CCS (memory allocation tool). 

Removed any constants inside header file, function decals or passing of constants into these SRAM loaded functions.

Invoking same while calls from SCIB initialization Flash loaded function into RAM loaded TX ISR handler causes illegal instruction fault. That Occurs single stepping from any break points into while call of SCIB ISR handler decals area.

Removing #pragma, SCIB ISR function goes back to Flash and runs without faulting. The while call (break point step into F5) asserts normally without same TX ISR faulting in flash memory space.

Also having issues with CLA task running code from same SRAM areas and causing same illegal instruction from completely different ISR code section.

The project HAL has option to increase Flash wait sates but did not help SRAM crashes even at 6 Flash waits.

The fault handler doesn't seem to care while calling from Flash to SRAM or from SRAM to SRAM as the same type of fault occurs.  

Q1: Is there a driverlib call to insert SRAM wait states?

Q2: Is there any undocumented errata for running SRAM loaded applications as slower SCIx ISR handlers?

  • 0
    TI__Mastermind 30185 points

    Hello,

    It will take me some time to look into your question, I will try to get back to you by Monday.

    Best regards,

    Omer Amir

  • 0 in reply to Omer Amir
    Guru 55603 points

    Hi Omer,

    Thank you for fast responding.

    I will also try making the entire project run from RAM this weekend and report any details.

    Regards,

  • 0 in reply to Omer Amir
    Guru 55603 points

    The SCI ISR illegal instruction exception occurs if the application is copied via #pargma into LSx range and not being in the same memory location where peripheral was copied to ram via FB0 code sections defined pages0-1. That was also causing mainISR() issues being copied into a different ram address without a full Sections definition (.TI.ramfunc :LOAD = FLASHB0_SA) created for #pragma CODE_SECTION(mainISR, ".TI.ramfunc"). SCIB ISR was copied from flash to ram LSx but was missing sections area page 1. C2000 compiler is omitting FB0 sections needed for CLA tasks to run.

    The compiler is not creating a new page 1 Flash sections area for Flash configured project when #pragma LSx are defined in page 0 of F28004x_cpu_is_flash.cmd file. Compiler only warns it did not create an FB0 sections it should do by #pragma ram address locations. Yet the CLA-LSx page 1 areas used the same CLA example section additions and FB0 (.TI.ramfunc :LOAD = FLASHB0_SA) via CLA setup mcopy.

    //
    // Copy the program and constants from FLASH to RAM before configuring
    // the CLA
    //
    #if defined(_FLASH)
    memcpy((uint32_t *)&Cla1ProgRunStart, (uint32_t *)&Cla1ProgLoadStart, (uint32_t)&Cla1ProgLoadSize );
    memcpy((uint32_t *)&Cla1ConstRunStart, (uint32_t *)&Cla1ConstLoadStart, (uint32_t)&Cla1ConstLoadSize );
    #endif //defined(_FLASH)

    See the map and flash cmd files in the next post

  • 0 in reply to Genatco
    Guru 55603 points

    Even creating page 1 FB0x sections for RamLSx_prog ram areas did not stop illegal instruction ISR exceptions. After the SCI application was mcopy(x.x) into any of RamLSx_ manual created Flash Bank 0 Section ram areas.  Perhaps ISR exception has something to do with .ebs or .cio storage areas not being accessible via other LSx ram address space after #pragma functions are mcopy() to these newly added sections?

    memcpy(&Ram1funcsRunStart, &Ram1funcsLoadStart, (size_t)&Ram1funcsLoadSize);
    memcpy(&Ram2funcsRunStart, &Ram2funcsLoadStart, (size_t)&Ram2funcsLoadSize);

    See attached F2800x49_cpu_is_flash.cmd file for details FB0 dedicated mcopy() page 1 sections.

    x49c-map-cmd.zip

  • +1 in reply to Genatco
    TI__Guru* 77460 points

    GI,

    Is it possible the ISR code is running from an unsecure memory or a memory that is in a different zone than your main code?  While function calls between secure regions is allowed(and passing of vars), if there is a global variable that is allocated to a different region that is secure it will read back 0x0000.

    If everything is allocated to the same zone, or security is off then this is not the issue, but wanted to make sure of that first.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Guru 55603 points

    Hi Matthew,

    Nothing LSx address regions have been forced secure in any of the project modules. 

    MatthewPate said:
    Is it possible the ISR code is running from an unsecure memory or a memory that is in a different zone than your main code? 

    The entire SCIB module is located in it's own LSx ram including the TX/RX ISR functions. Interestingly TM0 INT1.7 in another LSx address section calls SCI TX INT9.4, without issues when SCIB control section is loaded into ".TI.ramfunc" LS4_5 4096k.

    Yet when SCIB module is moved to another LSx address other than ".TI.ramfunc" an illegal instruction exception occurs immediately even before TM0 has chance to call the function that updates LCD number box widgets. The first thing SCIB INIT does send LCD command to switch from page 0 to page 1 where the number widgets get updated in intervals of TM0.  

  • 0 in reply to MatthewPate
    Guru 55603 points

    Hi Matthew,

    A few other possible issues being x49c datasheet Fig.3.1 has M0-M1 as 4KB where the Technical Brief shows two 1KB ranage. I'm aware of Advisory —Memory: Prefetching Beyond Valid Memory, flash CMD has M0(779 bytes), M1(1024 bytes) and M0(.stack 486bytes) and M2(Ctrl_Data 400 bytes). Since M0 is not defined Advisory end range (0x3FF) will M1 still follow M0?

    3.11.1.2 Local Shared RAM (LSx RAM)
    RAM blocks which are accessible to the CPU and CLA only, are called local shared RAMs (LSx RAMs). All such memories are secure memory and have the parity feature. By default, these memories are dedicated to the CPU only, and the user could choose to share these memories with the CLA by appropriately configuring the MSEL_LSx bit field in the LSxMSEL register. Further, when these memories are shared between the CPU and CLA, the user could choose to use these memories as CLA program memory by configuring the CLAPGM_LSx bit field in the LSxCLAPGM registers. CPU access to all memory blocks which are programmed as CLA program memory are blocked.  

    Does the word blocked mean how the RAM range is specified on an address boundary? 

    Bear in mind I disabled CLA configuration (hal.c) for above post attached MAP, CMD files. 

    Can you advise where to find CMD file sections proper syntax for LSx and GSx memory acronyms? 

    5.2.1 When a memory block is configured as CLA data memory, CLA read and write accesses are arbitrated along with CPU accesses. The user has the option of turning on CPU fetch or write protection to the memory by writing to the appropriate bits of the MemCfgRegs.LSxACCPROTx registers. A detailed explanation of the memory configurations and access arbitration (CPU, CLA, and DEBUG) process can be found in the Memory Controller Module section of the System Control and Interrupts chapter.

    Is it possible the write protection is not clearing on reset after CLA configuration was not being initialized during several flash erases? Oddly the CLA target is present (disconnected) inside debug secessions even after removing all terminated targets or closing IDE.

  • +1 in reply to Genatco
    TI__Guru* 77460 points

    GI,

    For the M0M1 question your allocation is OK, the restriction is only with M1 since the address range beyond 0x7FF is not memory/valid for prefetch.  The length in the cmd is correct, 0x400 words i.e. 1KW or 2KB.

    For the LS RAM, if used as CLA program memory, blocked here means that the CPU will not be able to read the memory, and I believe would return 0's either from a program fetch(which is ITRAP0) or data fetch.

    The write protection will be disabled on reset as you mention, you would be getting a ACCPROT ISR though if this was causing the issue, vs a ITRAP. 

    Do you know if the ACCPROT ISR is enabled/defined in your code?  If you are using our examples the ISR should have the standard asm(" ESTOP0") which will halt there if the emulator is connected.

    Once you get the ITRAP/Illegal instruction ISR, could you look at the CPU register SP(Stack Pointer), then open up a memory browser to the address listed in the SP?  You'll want to look before that address, say 20 words or so, and if you screen capture this and post it I can see if I can resolve the address the ITRAP0 came from, which will help us narrow down the offending memory region.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Guru 55603 points

    HI Matthew,

    I have the flash MAP file above working mostly Flash only firmware loads and RAMLS2 TM0 handler. The motor crashing or rotor rumbling after entering closed loop was caused by poor ground on analog input divider resistor. Oddly it completely stopped entering closed loop after making changes to F2800x49 flash CMD file Scream.

    When adding the #pragma to module functions SCIB INT 9.4 TX ISR and all serial processing commands, FIFO loads etc.. still causes illegal instruction exception but  SCIprintf() flash to ram calls are producing same ITRAP vector number. So I loaded SCIprintf() into LSx ram too and removed the constants in all the functions and headers, still gets the same ITRAP even from SCIA TX INT9.2.

    Oddly vector number 30 (USER 11) is not user configured and must belong to debug ITRAP exception handler?

    Oddly TM0 function ISR handler can remain in RAMLS2 but SCIB TX INT9.4 functions only work from Flash memory. TM0 handler call to vars update has several while calls to SCIB TXD (FIFO) even moved to RAMLS2 without need calling mcopy(2). SCIB TX ISR runs slower inside FB0 than in LS2RAM address space.

     

  • 0 in reply to MatthewPate
    Guru 55603 points

    Hi Matthew,

    Posted the debug memory results above. I noticed ITRAP0 was occurring at various places in the code after commenting suspect function calls in the command chain. If I commented out a call in a function suspected to cause ITRAP0, mcopy(x,x,x) would not copy those FB0 functions into RAMLSx. So it would seem like SCIB INT9.4 TX ISR was functional (No ITRAP0) up to the commented part then the SP, IP registers would stop instruction decode.

    At this point I am not so sure SCIB Flash application can ever run correctly in RAM LS0-LS7 without an added wait state or two.

  • 0 in reply to MatthewPate
    Guru 55603 points

    Hi Matthew,

    You may recall some time ago could not get SCIB or CPUTM0 30ms ISR calls to work with Instaspin 21µs ISR times. It seemed impossible a 30ms ISR could ever not over run 21µs ADC ISR especially in the same nesting group. However, I was finally able to get seamless behavior today after upon removing several while(branch to SCI TXD) statements that were required for TM4C129x MCU timer execution. Surprisingly not required when the serial output handler was made part of SCIB TXD function. Setting IER global priority for ADCC1.3 upon entry SCIB INT9.4 function was tricky. Also required to test PIEIFR flag INT9.4 was set prior to calling any function/s FIFO output into GPIO port. That last move made motor run much smoother in 21µs ADC ISR. The NOP advisory 4.1.1 may have helped B2B ACK writes in this case. 

  • 0 in reply to Genatco
    TI__Guru* 77460 points

    GI,

    Thanks for the update here, glad to hear the resolution on that nesting issue.

    Just to clarify from the previous post from your last one, is the illegal instruction still an issue from the posted issue of this thread?  Just want to make sure I'm not overlooking something here.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Guru 55603 points
    MatthewPate said:
    is the illegal instruction still an issue from the posted issue of this thread?

    Yes the module could not execute in LSx RAM as headers with (const char) seem to be required in several functions with flash memory. The SCIB ISR context was the caller to other module functions. May revisit CPUTM0 calls to SCIB with ADC ISR nesting but (TM0-SCIB) are in the same ISR execution context. 

    Perhaps  same issue, not first polling PIEIFR flags for jump to subroutine and CPU ready to write return address (.stack RAMM0). Perhaps PIEIER flags are early asserting CPU can accept peripheral data on the C2000 bus with modules copied to faster LSx RAM.  Oddly peripheral IER flags were set but never seem cleared in debug register view, only PIEIFR were toggling SCIB ISR modules in flash memory.