stm32f103/7.3.0 demo/usart

I started to work with FR a while back before being preempted to work on other bugs. When I left it I had LED’s working via the tasks created and all the other stuff in main commented out.  I have since gotten back to it and now want to get interrupts working. I have commented most of the other stuff out as below: xLCDQueue = xQueueCreate( mainLCD_QUEUE_SIZE, sizeof( xLCDMessage ) ); /* Start the standard demo tasks. */
//3 vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );
//2    vCreateBlockTimeTasks();
//    vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
//4    vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
//1    vStartIntegerMathTasks( mainINTEGER_TASK_PRIORITY );
vStartLEDFlashTasks( mainFLASH_TASK_PRIORITY );
vAltStartComTestTasks( mainCOM_TEST_PRIORITY, mainCOM_TEST_BAUD_RATE, mainCOM_TEST_LED );
     
First here is what it does: The xmit endlessly transmits a sequence of upper case letters (as it should). But when I send a char to the RX I get the interrupt but never get into the portTASK_FUNCTION( vComRxTask, pvParameters ) function. For the time being I have commented out the TX half. I read a long blog on priorities and it looked as if the demo had it backwards with the idle @ 0 and others at 191 andd 255 when you say that for ST the max is 15. I changed all these to go in reverse order but when I did, then nothing worked and i got stopped at HardFaultException. Can you take a look and comment on this? pmoyle

stm32f103/7.3.0 demo/usart

I read a long blog on priorities and it looked as if the demo had it backwards with the idle @ 0 and others at 191 andd 255 when you say that for ST the max is 15.
I don’t understand what you mean by “idle @ 0”.  If you are referring to the idle task, then it does not have an interrupt priority at all because it is a task, not an interrupt.  It does have a task priority of 0, but that is completely unrelated to anything interrupts are doing.  Task priorities being a purely software thing and interrupt priorities being a purely hardware thing. Please tell me which demo you are using so I can see how the priorities are configured in it.
But when I send a char to the RX I get the interrupt but never get into the portTASK_FUNCTION( vComRxTask, pvParameters ) function.
Can you step through the interrupt routine?  Does it post to the Rx queue without error (assuming you are using an Rx queue)?  Does the xTaskHigherPriorityTaskWoken parameter get set to 1 inside the xQueueSendFunction()? Regards.

stm32f103/7.3.0 demo/usart

0) the demo is the one in your chain at  ..FreeRTOSV7.3.0FreeRTOSDemoCORTEX_STM32F103_IAR
1) idle task with priority of zero was what I meant
2) I can step thru the isr
3) it does seem to post – I see it written into pxQueue, if that’s what you’re asking
4) xTaskHigherPriorityTaskWoken does get set to 1 New info: I was actually getting there one time, but I did not realize this because I didn’t set a breakpoint there until after I already pressed a few keys. I see some of what is happening: your loop is expecting a sequentially valued char and I was just poking a random char in to the rxbuf so that the code hits in else clause below and once happens, nothing seems to get it back. One frustration is that further down when I hit in the code below…. if( xResyncRequired == pdTRUE )
{
while( cByteRxed != comLAST_BYTE )
{
/* Block until the next char is available. */
xSerialGetChar( xPort, &cByteRxed, comRX_BLOCK_TIME );       ***** emulator loses break after this call
} /* Note that an error occurred which caused us to have to resync.
We use this to stop incrementing the loop counter so
sAreComTestTasksStillRunning() will return false – indicating an
error. */
xErrorOccurred++; I can never get out of the xSerialGetChar( xPort, &cByteRxed, comRX_BLOCK_TIME ); routine without the emulator running away. The emulator loses sync and the target let’s go. Usually, this is caused by either optimization being on or being in need of a “rebuild all” but I have optimization at low and did a clean/rebuild but still have the problem. That’s what fooled me. So I’m really get in there every time but after the first mismatch I can never seem to get back. If I start with ‘A’ and proceed ‘B’ then ‘C’, then skip to say ‘G’,  the next character that the watch says the variable is looking for is ‘D’ but neither that nor any I have tried A thru F ever gets it back. So I guess priorities are not a problem. Perhaps I was expecting some after reading that blog. I guess I’m most concerned about why I can’t step properly.  Any clue? Peter Moyle this flag gets set, I have to reset to start getting into the comrx routine at all. else
{
xResyncRequired = pdTRUE;
break; /*lint !e960 Non-switch break allowed. */
} what does

stm32f103/7.3.0 demo/usart

Yes – the demo is designed as a loopback test.  One task transmits and the other task receives.  The receiving task expects to receive exactly what the transmitting task transmits, so if you are sending anything else then it will always trap it as an error.  I think there is also a limit to the number of re-syncs it will allow before it just gives up. Regards.