Now for something completely different..;)

I'm having an issue with the stack that is stored when vTaskStartScheduler() is run is evidently restored as if a call to vPortEndScheduler() has been done - but my app. isn't calling any scheduler exit functions.

I've been able to catch with my debugger the exit and looked at the IRQ settings and they appear to be the same as when the scheduler is started. I change the settings once the app. is running.

Any ideas on what can be causing this to happen?
The crash can occur relatively quickly or can take 24+ hours to see. The intermittant ones are always the most fun - correct?

It's almost as if a portSAVE_CONTEXT was missed or an extra portRESTORE_CONTEXT is run which could have this affect. What could cause that?

One app. uses 3 DMA channels w/o IRQ's and doesn't have problems. The other app. uses 2 DMA channels but only 1 DMA IRQ - and that is the app. with the issue. I've tried disabling/enabling the DMA channels when portENTER_CRITICAL() and portEXIT_CRITICAL() were run - but that didn't solve the issue.

Thanks In Advance,
John W.

> I'm having an issue with the stack that is stored when vTaskStartScheduler()
> is run is evidently restored as if a call to vPortEndScheduler() has been done
> - but my app. isn't calling any scheduler exit functions.

Most ports have no way back once the scheduler has started - simply because there seems little point in implementing the scheduler end function unless there is something to return to. I would have though it unlikely therefore that you were actually restoring the original task stack unless this is something you have added to your port.

Is it possible that the board is resetting and calling main() again? If the startup code were not executed or not executed correctly then maybe the second time around the scheduler cannot start because the heap function is not re-initialised? Clutching at straws here.

> Any ideas on what can be causing this to happen?
> The crash can occur relatively quickly or can take 24+ hours to see. The
> intermittant ones are always the most fun - correct?

This is going to be a tricky one!

Regards.

Richard,

I suppose it's possible that the reset is occurring - I'm using heap_2.

I have implemented code for the scheduler to stop - but it's there just to 'catch' the error - it's never called - at least not on purpose. I also have yet to catch the call - so that supports that possibly the reset vector is getting hit or maybe the stack is just weed city when this happens.

Thanks,
John

Might help to say what port and/or hardware you are using

See here http://www.westmorelandengineering.com/

Jeff,

MSP430 - IAR port - done by me.;)

Note - the stuff posted on my web-site doesn't use DMA. I'm not sure if this has something to do with it or not at this point - I'm beginning to think it is more core to the port - something I've overlooked, left out, etc.

Feel free to go to my web-site and download one of the ports - or both - and check out the code for yourself. The demos. written for both boards on my site ran for weeks (more than 1 month actually) before I powered them off - so I know the ports - for what they are - are stable. Meaning the core code is very stable - or as stable as it can get in this world at least. With that known - it has to be what is different - correct? (Ah, Sherlock strikes again!)

I have one target that uses 3 DMA channels without IRQ's (they said it couldn't be done - but alas!) that will run basically forever like my demo. ports. The port with 2 DMA Channels - one using IRQ's - is the one that will croak intermittently.

I have to conclude that something about my DMA IRQ isn't correct - or maybe more precisely something about my port makes my DMA IRQ incorrect. I can run a similar scenario but at lower performance using RCV UART IRQ's - but my system spends too much time in UART RCV IRQ's which I'm trying to minimize. With DMA enabled - the performance is nice - I can get burst throughputs with DMA at 1MB - that's right - 1 MEGA BAUD. Not bad for the tiny MSP430. Of course I've done some things to enhance this - but nothing that breaks the architecture of FreeRTOS.

Thanks In Advance,
John W.

Hello All,

The forum has been a little quiet lately. I hope that means everyone has been coding away...

I changed my target mentioned above to use DMA without using IRQ's. The MSP430 allows you to do this - and it seems to be working OK. So I have to conclude something is amiss when enabling DMA IRQ's. I've looked at reentrancy issues regarding the DMA
code during an IRQ - and I don't see any in the code. I also put a 'wrapper' around the critical section stuff that disables DMA xfers and then re-enables - but the issue still happened with DMA IRQ's enabled. Disable the DMA IRQ - and it works . I was using xQueueSendFromISR and xQueueReceive in my ISR and task, respectively.

Regards,
John

>The forum has been a little quiet lately. I
>hope that means everyone has been
>coding away...

Nobody has any problems. Maybe it work so well?


I have used dma on RDC 186 ok.

It's good to hear that 'nobody' has any problems.

There's an old saying I'll repeat here - 'If you're not having problems - what you're doing is too simple.'

It appears that the problem I was having may have been due to too many DMA nested interrupts. I monitored usCriticalNesting and saw some rather large numbers - but this was after a crash and I wasn't sure or not the number was 'real'.

I'm running a test build now and will report later. My non-IRQ build has been running stably
for 48+ hours now.

Regards,
John W.