Hi Alexey,
The LIBUSB errors seem to be a red herring - when I first saw them I searched else where and it seems that Openocd searches for USB devices and tried a few before finding the right one.
I downloaded the latest Openocd-esp32 source from Github for Windows under msys and built it - it's a different version from the pre-built binaries. That adventure I'll document elsewhere to make it easier on others, but it wasn't too painful.
Now I have systemview working! And I have to say, it's a bit like going from guessing what's going wrong talking to an i2c device to having a hardware analyser. Amazing.
The Segger tool Systemview which the readthedocs mentions only in passing - I missed the link initially - is actually much more readable and easy to use than Impulse (and requires much less magic incantations). It's only downside is not having both CPUs visible, but for our purposes here, it is like magic. I had some regular dropped events - presumably there's a buffer I can increase somewhere to get over this, but I have enough data to show things.
So - back to the original problem. Occasional flickering during LED panel refresh.
You can clearly see here that the timer interrupt is firing and shortly after the panel_refresh is called. But notice how it goes into idle in between?
Code: Select all
EventBits_t mybits = xEventGroupGetBitsFromISR( panel_event_group);
if (mybits & PANEL_REFRESHING){
xEventGroupSetBitsFromISR(panel_event_group, PANEL_REFRESH_CLASH, &xHigherPriorityTaskWoken2);
} else {
xEventGroupSetBitsFromISR(panel_event_group, PANEL_REFRESH_TRIGGER, &xHigherPriorityTaskWoken);
if( xHigherPriorityTaskWoken) {
portYIELD_FROM_ISR();
}
}
My understanding is that the xHigherPriorityTaskWoken should kick off the yield which should make the actual panel refresh happen pretty much immediately (that task is running at priority 25), but surprise, the "portYIELD_FROM_ISR()" is not being called (confirmed by adding an 'else' to the if statement). The PANEL_REFRESH_CLASH was extra code to try and check if the refresh was being called while the panel was actually being refreshed (it isn't). I'm not sure why FreeRTOS doesn't understand there's a higher priority task, waiting to run. Interesting, and this code is common throughout the IDF, so I'd like to solve it, but that isn't a show stopper.
I am interested in this FROM_CPU1 task is though - and that it's purpose is. I'm just surprised that it's not SysTick-Scheduler-PanelRefresh.
But otherwise, give or take, we have a timer and (shortly thereafter) we have a panel_refresh. Fine.
But have a look at this one:
See how smack in the middle of doing a panel refresh, SysTick pops in to say hello. Now I have tried ALL sorts of things to stop this happening - to be clear I haven't tried these things and run SysView, but the result is the same (flickering), as mentioned in the original post. I really just want SysTick to take a holiday for a moment and let the panel_refresh happen as quickly as possible.
Any thoughts?
kind regards
Ian.