Hello,
I’m using V7.2.0 on Code Composer Studio 5.2.1.00018. I’m quite new to FreeRTOS and RTOSes in general) I’m getting two situations which appear to be crashes for the suplied demo. Once started everything seems fine. Pushing the joystick up an releasing it causes the screen screen to print messages about button up.  The red and yellow LEDs on the bottom are flashing reasonably.  The first crash case is that whenever I release the joystick button, the system crashes.  Occasionally with a mess of black on the screen, generally without.  The yellow and red light stop flashing once the button is released (nothing happens when it is pressed).  If I use the debugger I’m told I’m in 0xFFFFFE and below that “no source available for “0xffffe” (yes the number of Fs is different…)  I’d swear the first time I did this I was in some actual function, but I can’t rerpoduce that. The second is that after a while the board just stops working.  Lights stop flashing etc.    If nothing else is pressed after the screen clears everything stops after the 6th message on the new screen is printed (Status = PASS).  This behavior is quite consistant.  In this case I appear to be out of tasks?  I’m looping in vTaskIncrementTick and calling prvCheckDelayedTasks(); over and over.  Pressing the joystick select button at that time seems change nothing. Any help is welcome!

I’ve not tried in CCS5.  I downloading the latest version now, but it will take some time (it’s big!). In the mean time, can you tell me which data model you are using. Regards.

Hi,
Thanks for the response.  Just using the default, with is the large data model.

Hi,
Could you let me know if you are encountering the same problem or not?  I’m curious if I’m somehow doing something crazy.  Thanks!

- I can replicate your finding. - If I go back to the version of FreeRTOS that was originally released with this demo (which definitely did not have this issue) then the issue can also be replicated.  So it is not changes to the port, or to FreeRTOS that have caused the problem. - Commenting out the line halButtonsInterruptEnable( BUTTON_SELECT ); in prvSetupHardware() allows the demo to run ok (as expected, as it was the button interrupt that was causing the problem). Preliminary conclusion – a change between CCS4 and CCS5 is the root cause.  I don’t know what though, although looking at the interrupt processing would seem to be a good starting point. - Putting the call to halButtonsInterruptEnable( BUTTON_SELECT ); back in, but commenting out the call to xQueueSendFromISR() within the interrupt handler routine allows the interrupt to execute without any problem. - Editing the interrupt handler so portYIELD_FROM_ISR() is called does not cause the issue to return. Secondary conclusions – it is not executing the button interrupt itself, or yielding in the interrupt, that is the route cause. - Removing half the tasks, and then increasing the stack size of the remaining tasks makes no difference. - Putting everything back together, then placing a break point in the LCD task where the button interrupt message is posted, shows the interrupt is actually successfully sending a message on the queue and switching to a new task.  This is calling a low stack sprintf() function, defined in printf-stdarg.c. - Excluding printf-stdarg.c from the build (right click on the file in the project explorer and somehow find the checkbox that says “exclude from build”), do a complete rebuild, then try again and everything works as expected. Tertiary conclusions – there is something in the printf-stdarg.c file the compiler and/or linker is not happy with, even though the file is used with lots of other demos without issue. The call to sprintf() defined in printtf-stdarg.c works fine for all the other messages being printed out, it seems just when the button interrupt is pushed that the problem happens.  Please investigate that further and let me know what you find. Regards.

Thanks,
I’m going to have about 1.5 hours to work on it today and probably 3 on the weekend before I’ll need to move on.    Hopefully your notes will help!  I’ll let you know if I find the problem.

All I’ve managed so far is that the arg argument to print is wrong/corrupted.  So the copying of the string is looking for a nul and not finding one, so it’s trashing memory (and the code itself I believe).  Still working.

Got one of the two problems fixed.  To remind you there are two problems:
1. Pushing the interrupt button causes the program to stop.
2. After a while it hangs.  It seems to be a fixed amount of time.  Not sure if that’s a feature or a bug. 1: the problem was that “print” inside of printf-stdarg.c was running into problems on line 151.  The value “s” was pointing into random memory space and so the copy would just write until it found a .  The problem is that va_arg (ine 150) was passed an int as a type rather than a char*.  That was causing the value read back to be sign extended from a 16-bit value to a 20 bit value  (0xAEE8 to 0xFAEE8) in the cast to a char *.  So the fix is line 150 of printf-stdarg.c should be:
    register char *s = (char *)va_arg( args, char* ); 2: No clue at this time

OK, spent way too long on the second bug.  Can’t fix it or even narrow it down much.  Here’s what I know: In general the error is happening soon after the delaytasklist overflows.  It isn’t deterministic, but it seems to be in the general range of 200-800 ticks after the overflow (when xNumOfOverflows first increments). The pxDelayedTaskList is getting trashed.  It looks a lot like something is walking into the structure (overflowing copy as before?).  Many of the pointers are becoming ffffffff. I also learned a lot about Eclipse (which will likely prove useful for me later).  Any help here this weekend would be wonderful-I’ve got a class full (ok, just 16) of students who I want to have using this board on Thursday using FreeRTOS but it ain’t working for now… Thanks,
Mark  

Does it still not work, even when you remove printf-stdarg.c. from the build as I suggested? Regards.

I can still replicate the problem with the large/large model.  Assuming using CCS4 or IAR is not an option, I have found that, with the printf-stdarg.c file removed (it was originally added because of issues in the CCS4 libraries), the small data small code model is working fine.  Hopefully you can give your class with that.  Please let me know if you work out the large data model issue. Regards.

Thanks,
Have changed to the small data model and excluded the file from the build and all seems well. Thank you so much!
Now off to write a lab… Mark

Odd, I thought I’d made another post here saying thanks.  Sorry if this is a repost In all cases, thanks so much for the help.  Lab is at http://www.eecs.umich.edu/courses/eecs498-brehob/Labs/Lab5.pdf 
FAQ follows:     My board keeps getting a “break” in the code randomly even though I have no break points.  What’s up?
        Your board is faulting for some reason.  This can happen for two basic reasons.
            You have a power problem.
                The LCD on the board isn’t well behaved when not powered on (I’ve no clue why).  If you connect the top-left jumper on the board this should help.  Another symptom of this problem is that the outputs on the board aren’t consistently driving to the same Vcc point. 
                You are running off of battery and they are failing.  Change the power switch to USB and connect the USB power.
                You haven’t fully connected the USB power.  It takes a bit of force but should go most of the way in.
            You didn’t change to a small memory model.  No clue why this causes problems (the guy who wrote FreeRTOS is also confused as it works correctly under CCS4!).
            
    I can’t get the buttons to work correctly for interrupts.
        Check out Demo_Source -> MSP-EXP430F5438_HAL ->hal_buttons.c for how to initialize the buttons.  This doesn’t set up the interrupt stuff, but it does the rest.