Strange Behaviour in FreeRTOS 8.0

Hi, I`ve installed 8.0.0 according to instructions, including changing all types to match those in the FreeRTOS.h header file. These are the only changes I have made from 7.5. I also set the flag in FreeRTOS.h – configENABLEBACKWARDCOMPATIBILITY to 0. Program compiles with no errors or warnings. After loading and running the software, it`s hanging up, and the processor being reset by the WDT as prescribed intervals. At this point unable to ascertain where the issue is. What would have changed that could be causing this – recalling that everything in 7.5 was working just fine?

Strange Behaviour in FreeRTOS 8.0

I am not aware of anything that would cause this when upgrading from V7.6.x to V8, however as you have come from V7.5 it may be related to additional error traps included in V7.6.x. 7.6.x includes some additional configASSERTS() statements to trap common misconfigurations on some architectures (you don’t mention which architecture you are using) and it is possible you are hitting one of those. Have you tried placing a break point in your assert handler to see if it gets hit before the watchdog resets the system? Regards.

Strange Behaviour in FreeRTOS 8.0

Ok, thanks for that info on the 7.6 release. I did not have an assert defined so I added that. Also created a function to handle the assert calls, but it never gets called – includes a DBG output and breakpoint. It’s on an LPC1768, using IAR EWARM 7.0 Thanks for any other suggestions as to what I could try.

Strange Behaviour in FreeRTOS 8.0

EWARM 7 only just came out. Did you try using FreeRTOS 7.5 with EWARM 7?

Strange Behaviour in FreeRTOS 8.0

Hi, Yes. I can compile and run with no issues with RTOS version 7.5 and EWARM 7. Before updating EWARM to v7, I tried version RTOS v8.0.0 with EWARM 6.7.2. Didn’t work there either: same issue, just ends up resetting LPC1768. Where can I get a 7.6 version of FreeRTOS? Perhaps I can try that and see if there are any issues with that version…

Strange Behaviour in FreeRTOS 8.0

I’ve installed version 7.6. It works with no issues at all under IAR/EWARM 7. So it looks like a possible bug in FreeRTOS v8.0 with this device, and/or EWARM 7?

Strange Behaviour in FreeRTOS 8.0

Hmm. I presume as you are updating a previous project to V8.0.0 you are not using any of the new features in V8.0.0, so there must be something in the pre-existing features that is causing your application to behave differently. Other than the changes in the type names there are not too many differences in the pre V8 features so that will help narrow this down. So one step at a time – in your original post you noted you had changed your application to use the new type names, then turned off the backward compatibility. Did you try compiling and running your application before you did this – so with your application completely unmodified and only FreeRTOS source files changed (so the old type names in your application were #defined to the new type names by the macros at the bottom of FreeRTOSConfig.h which are removed when configENABLEBACKWARDCOMPATIBILITY is set to 0)? If that does make a difference then we can concentrate on that line of enquiry, if that doesn’t make a difference (i.e. the issue still exists) then the next thing to look at is the code that should be kicking the watchdog to determine why it is not being kicked…Is your application kicking the watchdog from several locations, or do you have one task/function/whatever that is monitoring the whole system before the watchdog is kicked. If you have a central watchdog function then we need to determine why it is deciding not to kick the watchdog – is the task/function deciding not to kick the watchdog because a test is failing or it the task/function failing to kick the watchdog in time simply because it is never being called? Regards.

Strange Behaviour in FreeRTOS 8.0

To start, I deleted and reinstalled FreeRTOS v8. Then, on IAR, I started from a working copy of the project, and made incremental changes to go from v7.6 to v8.0. That includes changing all defines in code and setting the #define configENABLEBACKWARDCOMPATIBILITY to 0. It’s now operating with no issues. Still a bit of a mystery as to how it compiled before – including a clean and build – and yet still crashed while running. Thanks for your patience and help as I worked through this. 8–)