• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 797 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.

TMS320F280023C: SPI write fails when I add a line of code

Vishnu Venkatesh
Prodigy 190 points

Part Number: TMS320F280023C
Other Parts Discussed in Thread: C2000WARE

Hello,

I'm facing an issue where my SPI writes fail when I add a line of code.

The hardware setup is an F280023 microcontroller interfaced to a DRV8304S that controls a BLDC motor. The registers in the IC are configured through SPI.

I cannot share the full code, unfortunately, but I can describe it and probably share some snippets. The int main() code structure is as follows:

  • First there are some initialisation functions. The peripherals used are: timer0, timer1, ADC-A, ADC-C, SPI, SCI, and ePWM1/2/3.
  • Then there is a main loop that essentially runs the motor in a few different "modes" (speed control, torque control, PWM control, etc). It's essentially one big switch-case in the main loop that controls execution flow.
  • The interrupts that run regularly are:
    • SCI interrupts for communication with another board.
    • GPIO interrupts for commutation based on hall values coming from the motor.
    • ADC interrupts which are triggered from the ePWM module (midpoint of PWM high) to sense phase currents.

When I add a line of code in main, then my SPI communications fail. Here are some observations:

  1. The line of code is not in the execution path of the code upon startup. It is in a section of code that is only accessed when I change a switch-case variable to enter a different execution path in the debug window. Still, the SPI communications that happen in the setup phase - before the switch-case is ever entered - seem to fail.
  2. On the oscilloscope, the MOSI line just shows seemingly random level changes. Photo attached below. This waveform repeats endlessly.
  4. It doesn't seem to matter what the line of code is. Whatever extra code is added seems to cause the issue. Specifically, I was trying to write into an array each loop to monitor the values of a particular variable, but even when I swapped out that statement for a normal addition statement with dummy variables or even duplicated the , the same failure condition arose.
  5. I thought it might be something to do with the stack/heap size, so I increased the memory allocated for those in CCS Linker options. Didn't solve the issue.

I understand this might be a vague description of the issue, even I'm trying to find out other useful clues. If I could get some pointers on other things I could look at to debug this, I would be very grateful.

Regards,

Vishnu

Edit: Some changes in the code occasionally produce a different sort of error - code freezes in the following area of boot ROM, which apparently happens if there is an illegal instruction trying to execute. It is still unclear what exactly causes this, since the code compiles just fine even when the error occurs.

  • 0
    TI__Guru 55700 points

    Vishnu,

    When you get an illegal instruction error (ITRAP) error, you need find the which instruction caused that error. In my experience, it is generally memory corruption caused by stack overflow (or) so other code changing a section of memory unintentionally. I would encourage you to load the boot rom symbols of F28002x bootrom.

    1) Load boot rom symbols

    Path: C:\ti\c2000\C2000Ware_4_03_00_00\libraries\boot_rom\f28002x\rev0\rom_sources\ccs_files\cpu\Release

    File: F28002x_ROM.out (BOOTROM COFF file)

    2) Then you need to locate the file and select

    Path: C:\ti\c2000\C2000Ware_4_03_00_00\libraries\boot_rom\f28002x\rev0\rom_sources\F28002x_ROM\bootROM\source

    3) The above two steps load the boot rom symbols and associated bootrom file. Then in expressions window you can check the variable CPU1BROM_itrapAddress to get the address location which triggered illegal instruction trap condition.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    Prodigy 190 points

    Hi Manoj,

    Thanks for the suggestion. However, I have not been able to reproduce the ITRAP issue consistently in my system. It only happened once, when I made a random change in the code for debugging, and I mentioned it because I thought it might be relevant.

    The only thing that happens consistently for a given version of the code is the SPI failure. Of course, versions of the code for which the SPI issue is not observed will never have an issue later on. But the bizarre part is that the changes that lead to these SPI writes failing is quite random - replacing a line, commenting an unimportant part... From what I have seen so far, these code changes have nothing to do with SPI, and yet this SPI failure is the only thing I have found that seems to fail consistently.

    If stack overflow is the issue, shouldn't increasing stack size fix it? I tried doing that (Properties -> C2000 Linker -> Basic Options, and changing stack size from 0x200 to 0x300), but the problems still persisted.

    Regards,

    Vishnu

  • 0 in reply to Vishnu Venkatesh
    TI__Guru 55700 points

    Vishnu,

    I don't think we have all the pieces of the puzzle to understand what is going on. You need to debug and narrow-down the problem further for me to understand this problem. Understand what changes the code flow and see which conditions have your device go off weeds.

    Regards,

    Manoj