MSP430 and SYS/BIOS

Hi Yves,

I was just able to successfully build, load, and debug the SYS/BIOS "Task Example" project using CCSv5.5.0 and an MSP430F5529 LaunchPad EVM.  I was able to set breakpoints in the task myTaskFxn and the Hwi myTickFxn and successfully halt the CPU on both.

Which SYS/BIOS project specifically are you having trouble with?  I'll try it on my end to see if I have any problems.
Outside of the breakpoint issue, do the demo projects behave as expected?

Regards,
Walter

Hi Walter,

The project is "task430_MSP430F5438A".  The target hardware is MSP-TS430PZ5x100 with a MSP430F5438A in the socket; no additional component (except for the FET430UIF debug interface).

The code seems to be running but if I pause the debugger, the instruction is

    __bis_SR_register(Power_module->idleMode);

at line 72 of file Power.c.

Regards,

Yves

Hello Walter,

Are you still monitoring this thread ?

Yves

Yves,

The behavior you are seeing makes sense.  The task430_MSP430F5xx SYS/BIOS example is configured to have CPU idle time enabled, with low power mode 0 selected (LPM0).  Since the example project does very little in the task function, most of it's time is spent pending on a semaphore.  Since there are no other tasks, not even and idle task, this translates into CPU idle time: which is configured to be a low power mode for the device. 

If you pause the debugger while the application is running, chances are very high that the CPU is idling in a sleep mode at that time, since there is not much code to execute in the example.  This is why you end up in the power file.

The configuration for CPU idle is available in the SYS/BIOS *.cfg file.  Below is the example project configuration:

You can turn off CPU idle capability by unchecking the box.  If you do this, then hit the pause button as you have been doing, you will end up stopping in the Task_allBlockedFunction() API in task.c, since you are now just spinning CPU cycles rather than sleeping the CPU.

I still do not have any issues on my end with hitting breakpoints in the task if I set them.  Are you still having problems with this?

Regards,
Walter

Walter,

I turned off the CPU idle capability and when I hit the pause button, it stops in "ti_catalog_msp430_init_boot_configureDCO() at Boot.c:139"

The problem is not with breakpoints : the tasks never run !!!  I inserted an instruction to toggle the LED when the task starts but the LED never changed.

All the examples for a MSP430F5438A (running on a simple eval board) DO NOT WORK !!!

Regards,

Yves

Yves,

I have now checked the task example on an F5438A device on the 100pin target board, in addition to the F5529 device.

I did not have any issues getting the example project to run out of the box.

When you enabled the LED toggling, did you comment out both the port initialization ( P1DIR |= 0x1;) as well as the toggle (P1OUT ^= 0x1;)?

Another way to view whether the application is running or not is to open the "Raw Logs" view and pause the target.  If it is running, you'll see the SYS/BIOS log messages.  You'll need to let the target run for 5-10 seconds to fill up a couple log messages to view.

I was not able to find ti_catalog_msp430_init_boot_configureDCO() in Boot.c.  Which version of SYS/BIOS and XDC tools do you have installed?

You should be able to find this out by looking at the directory names in C:/ti/bios_...

Regards,
Walter

Walter,

The LED pin was configured correctly.

SYS/BIOS installed versions : 5_42_01_09 and 6_35_04_50

XDCtools : 3_25_03_72 and 3_25_04_88

My project uses the latest (underlined). CCS version is 5.5.0.00077

Any help is appreciated,

Yves

Walter,

Do you think it has to do with the versions I'm using ?

Yves

Hi Yves,

No, I the version should not have an impact on whether the example works or not.  I wanted to compare your version to mine to ensure we were using the exact same example.  To that end, I've attached a ZIP archive of of my CCS project that works on my target board with an MSP430F5438A.  I have the same component versions that you do.

5807.task430_MSP430F5438A_LED.zip

If you download this project and attempt to run it, and it works, then please send me a copy of your project so I can try to help you pinpoint what the problem is.  If you download this project and it doesn't work, we'll have to dig a little deeper to see what the issue is with your toolchain.

Walter

Hi Walter,

Your project works !!!

I'm sending you the original project as it was imported from "TI Resource Explorer".

Thank you,

Yves Belanger

5165.task430_MSP430F5438A.zip

Hi Walter,

I compared the projects and noticed a difference in the code size : the working code size is 12 bytes smaller.  I also compared all the project's source files and found that the problem comes from the .cproject file.  The defective .cproject file has an extra line :

<option id="com.ti.ccstudio.buildDefinitions.MSP430_4.2.linkerID.CINIT_HOLD_WDT.728955437" superClass="com.ti.ccstudio.buildDefinitions.MSP430_4.2.linkerID.CINIT_HOLD_WDT" value="com.ti.ccstudio.buildDefinitions.MSP430_4.2.linkerID.CINIT_HOLD_WDT.on" valueType="enumerated"/>

If I manually remove that line from the .cproject file and rebuild the project, it works !!!

I even managed to get your working project to not work : I used the "Show Build Settings .." to change the XDC tools version (from 3.25.3.72 to 3.25.4.88) ...

In conclusion, CCS seems to insert the HOLD_WDT line in the .cproject file every time something is changed with the "Show Build Settings ..."

Regards,

Yves Belanger

Yves,

The --cinit_hold_wdt is a linker command option.  You can adjust it in your CCS build settings (as shown below) which is probably why you see it update whenever you open your build settings, since CCS is probably updating the project file.

The command option is explained in the C/C++ Compiler User's Guide:

I have also noticed that your project defaults to having this option set to "ON."

The watchdog timer, in its default, post-reset state, will trigger a device reset when it times out.  If the watchdog timer is not disabled by the program, then the device will continuously reset.

As we can see from the source code in the example, there are no lines controlling the WDT.  I did notice that the XDC tools have the _system_pre_init symbol defined, so they may be doing it in there.  I'll have to check with the SYS/BIOS group on this setting.

I'm not sure why CCS set that automatically for you, it should have pulled the project-spec settings from the example.

Walter

Yves,

Come to think of it, if flipping the --cinit_hold_wdt option causes the _system_pre_init() symbol to switch to the RTS auto-initialization routine, as opposed to the XDC tools routine, which is probably required by SYS/BIOS, SYS/BIOS may not be correctly starting since it's pre-init routine was not linked.

I will verify this with the SYS/BIOS experts.  It would explain the problem, but not why that setting got set by default when you imported the project.

Walter