CCS/TMS320F28379D: Same code runs on the launchpad but cause ILLEGAL_ISR() on control card

Hi ,

The clock freq (OSC) is different bewteen the LaunchPad and the Control Card . LaunchPad has 10MHz XTAL whereas the Control Card has 20MHz XTAL.

Apart from this, the GPIO pins are brought out differently on the Control Card and Launchpad.

I think the error is due to the incorrect clock configuration.

You can refer the file "C:\ti\c2000\C2000Ware_3_03_00_00\device_support\f2837xd\common\include\device.h" and search for "#ifdef _LAUNCHXL_F28379D" to know the differences.

Best Regards

Siddharth

Dear Siddharth,

Thank you for your response. I saw the difference in device.h, however, I am wondering where should I declare the difference in my project? (e.g., change or comment out which lines in what header files?)

Very much appreciated your help!

Best,

Jingping

Hi Jingping,

If you are using the same file "device.h" in your project , then you can define "_LAUNCHXL_F28379D" as a pre-defined symbol in CCS compiler options.

If you are not using this file, then you must change the code for the Launchpad by referring to the device.h file.

Best Regards

Siddharth

Dear Siddharth,

Thank you for the clarification. If I am using the control card, then I don't need to pre-define the symbol in CCS?

I am trying to migrate my project from the 28379D launchpad to the 28379D control card. I am using both CPUs for my project, where CPU1 conducts power electronics control and CPU2 uses SPI to communicate with a Raspberry Pi 4. When I testing my code on the control card, I did connect the peripherals (power electronics) for CPU1. The data sent over SPI are the power electronics measures in CPU1 and leverage shared memory + IPC to put into SPI TX buffer in CPU2.

The entire project works fine on the launchpad, but I encountered some other issues using the control card in addition to the one I posted before. And I list the current issues I meet:

1. Connecting to the control card, when start the debug session, the first time it will have “Error initializing flash programming”. When I quit this debug session and start over it works as normal. For each successful debug session, there will be an error debug session before it. However, this never happens to the launchpad. I am wondering if this phenomenon is normal?
2. Since I don’t have the power electronics peripherals connected, I currently assign some arbitrary data to mimic the measures in the interrupt as shown below ( the screenshot from CPU1, the initialization values for all those variables are set to be 0):

-       If I use line 572-575 to define testValue instead of line 571, in the debug session, I directly trigger the ILLEGAL_ISR() when I run CPU1.

-       If I use line 571 to define testValue instead of 572-575, in the debug session:

 1) sometimes ILLEGAL_ISR() is triggered when I start running CPU2

2) sometimes using the exact same code, it doesn’t trigger the ILLEGAL_ISR() when I run both CPU1 and CPU2. It successfully enters the interrupt in CPU1 (testValue and V1_meas_avg, and etc. has values) And the values are successfully put in the shared memory (sData_32 has value in both CPUs).

-       If I use line 571 to define testValue and set the value to be 2.0 instead of 2.1. I can run both CPUs without triggering the ILLEGAL_ISR(). But it does not enter the interrupt (all variables remain 0).

All those errors and issues do not make sense to me. Using the same code, the launchpad behaves differently in different trials. I am wondering what’s the reason for these “wired” behaviors.

 3.     Using the successful trial in 2 (use line 571 to define testValue, and CPU2 successfully get the shared value), the SPI RX/TX interrupts on CPU2 are not triggered when connecting to Raspberry Pi 4 (RPI is the master and keep sending data).

Running the same code on the launchpad can successfully conduct the bi-directional communication with Raspberry Pi 4. I am wondering does the difference in the CPU clock between the launchpad and control card also affects SPI? Do I need to change something for SPI manually?

Thank you so much for your kindly help!

Sincerely,

Jingping Nie 

Hi Jingping,

Yes, if you are using the control card, you need not define the symbol.

Regarding your questions , please find response below

1. This does not look normal. Looks like some code is preventing the flash utility to run and erase. Usually the code which erases/programs the flash is downloaded from a dll to the MCU and then executed. In this case, looks like the code that you have programmed is preventing it from downloading/executing the flash utility code.

2. Can you check the disassembly and see what it is the opcode generated for lines 572-575? Is testValue a global variable? I am also checking with our IPC expert regarding this.

3. SPI bit rate depends on the CPU freq. Hence you have to ensure that the PLL and clock are correctly configured for the control card.

Best Regards

Siddharth

Jingping,

Please also be aware that the LAUNCHXL_F28379D uses a 10-MHz crystal, whereas the TMDSCNCD28379D uses a 20-MHz crystal.

The TI examples look for the "_LAUNCHXL_F28379D" predefine symbol to differentiate between the two board builds.

-Tommy