Can't get scheduler to run anymore

travfrog wrote on Friday, April 26, 2013:

It also occurs to me that when stepping with the debugger, the timers may be disabled so you can step successfully because timer ticks are not happening - if you stepped long enough you might see the problem. When running normally, timers are running and the problem may well be showing up when a timer expires or rolls over or the system tick interrupt fires. The nature of what you are seeing tells me something is triggering and then calling a bad address.

moto95 wrote on Friday, April 26, 2013:

travfrog, the code shown in post 19 is literally ALL of the code for the experiment described in that post, aise from the completely unmodified FreeRTOS source code. It does not use a tick hook function and FreeRTOS is configured not to use one. In earlier examples, I did use a tick hook function but that was just for troubleshooting purposes.

Your suggestion about this being a timer related problem would make sense to me, mainly, as you suggest, due to the single stepping working OK. How can I investigate a potential timer issue? I am not using any timers, aside from whatever FreeRTOS does with timers.

Richard suggested in post 13:

…just wondering if it could be something to do with the software interrupt not being installed correctly. The software interrupt is used for yielding.

How do I check this?

moto95 wrote on Friday, April 26, 2013:

A small further update. I’ve gone back to a previous project that uses a PIC24, and that works fine. The MPLAB-X and FreeRTOS versions are exactly the same. I’ve also run the code from post 19 on a PIC24 target using the same MicroStick-II kit and it it works as it should. But, it stubbornly refuses to work on a PIC32 chip. Letting it run without the debugger, it crashes the first time it calls vTaskDelay(). It sure sounds like it tick/timer interrupt related.

rtel wrote on Friday, April 26, 2013:

The curious thing is that you said it was working - but now it is not - which would imply that the code itself is ok but maybe something in the project settings are not right.  I presume you are aware that different PIC32 devices require different configuration bits set.  That is evident by the following code in the main.c file from the official PIC32 demo:

#if defined(__32MX460F512L__)
	#pragma config UPLLEN = OFF
#elif defined(__32MX795F512L__)
	#pragma config UPLLEN = OFF
	#pragma config FSRSSEL = PRIORITY_7
#endif

There were some changes to the PIC32 code between FreeRTOS V7.3.0 and V7.4.0 to remove any dependencies on the Microchip software libraries.  Although the V7.4.0 code was thoroughly tested it would be an worthwhile experiment to try replacing the files in Source/Portable/MPLAB/PIC32MX/ with those from the V7.3.0 distribution

Failing all that, if you zip up the tiniest project that exhibits this behaviour, making sure there are no absolute paths in the project that would prevent it building on a different computer, and send it to the business contact email address we can take a look.  I don’t have the exact same PIC32 part as you though.

Regards.

moto95 wrote on Friday, April 26, 2013:

Many thanks for your assistance, Richard. And, for your offer to test the code. Hopefully, I won’t need it.

Yes, I did see the config variations. Why, though, does the USB PLL need to be disabled? Not that I am using it. And, what should the shadow register priority be for the MX575 chip? Are there other config settings that are prescribed by FreeRTOS for the MX575 chip?

I’ll give this a try tomorrow morning, and report back. Any additional guidance for FreeRTOS dependant configs would be be great.

moto95 wrote on Saturday, April 27, 2013:

OK. Progress, at last!

Adding the following line made it work again:
    INTEnableSystemMultiVectoredInt();

I’ll be honest and I can’t remember whether this was included originally or not, how it got deleted, etc. I found this only by looking at various Microchip code examples, specifically Timer1 related. I presume this is was a complete rookie mistake on my part, and I will study the ConfigPerformance files in the PIC32MX FreeRTOS demo.

The config settings in post 24 didn’t have any affect on the problem, btw. Thanks for everyone’s help.