I’m working on a port - have a lot working:
Main timer IRQ is OK - I’ve verified xTickCount to a wall clock, it may not be perfect, but it’s close.
I have blinky in the IDLE task - it runs fine.
I’ve enabled tasks and I’m seeing xNextTaskUnblockTime on the order of seconds vs. what I would expect to be milli-seconds.
So, this would appear to be a scaling problem - I have configTICK_RATE_HZ, configCPU_CLOCK_HZ, and portTICK_PERIOD_MS set correctly - again, xTickCount is correct or close enough.
I’ve verified xNextTaskUnblockTime is larger than it should be, and have timed it ticking down, and watching the tasks switch in super slo-mo.
I’ll keep digging, but I was hoping someone could chime if this is a known issue and/or there’s some new config option I may have missed. I’ve looked at a few of the newer ports, nothing is jumping out at me.
I see it will get set to portMAX_DELAY as an initial value; but I’m not intentionally trying to do a tickless IDLE.
In the debugger I was seeing very large values being set when vTaskDelaly(100); - meaning 100ms but the number in xNextTaskUnblockTime represented a number more like 100 seconds - just though maybe there was a scaling issue and maybe some port definition I had missed.
Yes - that’s what I have started - I changed a few things to see how xNextTaskUnblockTime was scaling - and it wasn’t/isn’t doing what I expected.
The issue with this particular port right now is that I don’t have an easy way to double check how fast vTickISR is really happening other than setting a counter as a “wall_clock” and looking at xTickCount - I changed my rate of interrupts - but it didn’t appear that xNextTaskUnblock changed. I’ve been able to pipe out the main clock - but on this board/architecture - I don’t have an output specifically for the timer I’m using - and right now I don’t want to do an I/O anywhere inside the timer IRQ stuff. So, this is an interesting problem.
It’s been a little while since I did a port completely from scratch; I have noticed there are quite a few more asserts than before - I guess that’s OK.
I have seen an assert that claims the scheduler is stopped - but I have uxSchedulerSuspended in a watch window and it’s 1. So, not sure why that is happening right now.
This design has plenty of RAM for what I’m trying to do - I’ve enabled stack checking - that failed until I changed the check string to 0xa5a5 by the way.
I my last build - I have one task that takes a binary semaphore, blinks the LEDs - and then suspends waiting for the semaphore. Another task feeds the semaphore. The IDLE task is running too - all this runs OK - but just runs a bit slow unless I increase the rate of the vTickISR; which in my opinion right now isn’t an ideal solution, but it works.
Wanted to ask in case this is indicative of something non intuitive - I have the port running - doing debugging - but sometimes when single stepping (note right now I don’t have anything setting portMAX_DELAY) - but sometimes it appears the xNextTaskUnblockTime gets reset to portMAX_DELAY and at that point the debug session is blown as far as trying to wait for the next event.
I’m beginning to think my PC is getting reset and going back to the init of vTaskDelay() and that could explain this - not sure yet - but just wanted to mention that in case someone has seen this before. The target isn’t resetting - but I’m not sure the context swithing isn’t possibly having some kind of second order effect. Note I don’t think I’m seeing this on any of the semaphore delays - just the vTaskDelays(). I had vTaskDelayUntil() in the code until I figured out this issue - just thought vTaskDelay() would be easier to debug.
I am using the latest v10.1.1 pulled down from SVN.
Can you put a breakpoint at the start of main() to see if it gets called more than once when you are debugging? Is you debugger still processing interrupts between debug steps (causing confusion in what you are seeing)?
Yes - I’ve been doing that - and IRQ’s are supposed to be stopped while debugging…but…
there’s a DBSTAT ‘register’ - and it isn’t memory mapped - but if I clobber that, all bets are off.
So, that could be the reason. I thought I had fixed that - but, it could be the reason. The chip manufacturer wasn’t very informative other than telling me in so many words not to touch DBSTAT. Since it’s on the sysStack, if that stack gets changed in any way DBSTAT does not like; I guess that leads to debugger issues. Also, this register isn’t memory mapped (as far as I know).
It would obviously be helpful if it was.
Part of the PC and another register are adjacent to DBSTAT too; making the possibility of it getting changed pretty high. Anyway, just add another level of complexity.
I’m making progress; hopefully I will have something I can call release/example 1.0 soon.
I think the DBSTAT issue is OK now - I’m seeing some tasks get placed in the suspended state that had a vTaskDelay() of 100mS - and they never are unsuspended. Other than some obvious issues with maybe something being reset like the count-down counter - do you have any suggestions on how to figure that out?
If I try to debug this for any amount of time - I’m landing here:
for( pxIterator = ( ListItem_t * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext ) /*lint !e826 !e740 !e9087 The mini list structure is used as the list end to save RAM. This is checked and valid. *//*lint !e440 The iterator moves to a different value, not xValueOfInsertion. */
I don’t think I’ve seen that before either. I think I know what’s going on now - I thought I had locked this processor’s way it handles the stack - it has two stacks - and I just noticed one stack pointer was incrementing/decrementing independent of the other one (system stack pointer). Didn’t know that was happening or even possible after setting the stack mode; but maybe something is resetting that. So, yes, is it stack related - looks that way - but this is “stacks” related.