Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

'Virtual Call' of vPortEndScheduler()

Posted by John W. on May 17, 2006
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.

RE: 'Virtual Call' of vPortEndScheduler()

Posted by Richard on May 17, 2006
> 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.

RE: 'Virtual Call' of vPortEndScheduler()

Posted by Nobody/Anonymous on May 19, 2006
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

RE: 'Virtual Call' of vPortEndScheduler()

Posted by Jeff Smith on May 19, 2006
Might help to say what port and/or hardware you are using

RE: 'Virtual Call' of vPortEndScheduler()

Posted by Nobody/Anonymous on May 19, 2006
See here http://www.westmorelandengineering.com/

RE: 'Virtual Call' of vPortEndScheduler()

Posted by John W. on May 20, 2006
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.

RE: 'Virtual Call' of vPortEndScheduler()

Posted by John W. on May 25, 2006
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

RE: 'Virtual Call' of vPortEndScheduler()

Posted by Nobody/Anonymous on May 25, 2006
>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.

RE: 'Virtual Call' of vPortEndScheduler()

Posted by John W. on May 26, 2006
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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists