search

min-protocol / min

The MIN protocol specification and reference implementation
257 stars 88 forks source link

MIN protocol not working properly on TI MCUs but works on STM #23

Open ArielSmarTap opened 4 years ago

ArielSmarTap commented 4 years ago

Hello, Have someone succeeded in running the protocol smoothly on TI MCUs? it's working for me only on STM32F303VE but it's not working on TI RM41L232 and TI CC3200MOD

1. ON STM ITS WORKS like this: void HAL_UART_RxCpltCallback(UART_HandleTypeDef huart) { if (huart->Instance == UART4)//STM2DebugPort { / Receive one byte in interrupt mode / HAL_UART_Receive_IT(&huart4, &STM2DebugRxByte, sizeof(uint8_t)); min_poll(&STM2DebugMin_ctx, (uint8_t )&STM2DebugRxByte, sizeof(uint8_t)); } }

2. in CC3200MOD its can work slowly, but only if I pull the whole data from the UART interrupt handler Rx buffer at one shot. When I get an 0x55 byte (EOF) I'm pulling the buffer (SOF to EOF) at one shot from a different thread (Task) - SEE BELOW CODE

void Uart0IntHandler(void) { / Receive interrupt / if (MAP_UARTIntStatus(UARTA0_BASE, false)); { MAP_UARTIntClear(UARTA0_BASE, UART_INT_RX); / Clear Interrupt / while (MAP_UARTCharsAvail(UARTA0_BASE)) { / get the byte from the usart and push to rx buffer / lRcvByte = (uint8_t)MAP_UARTCharGetNonBlocking(UARTA0_BASE); if (lRcvByte != -1) { STMTxWifiRxBuff[idx] = lRcvByte; tmp_byte = lRcvByte; Report("%x ",tmp_byte); /check if we have reached to EOF then poll on other thread/ if (tmp_byte == 85) dataReady = true; else idx++; } } } }

the polling thread is: void Uart0Poller(void) { if (dataReady) { dataReady = false; min_poll(&STM2WiFiMin_ctx, (uint8_t*)&STMTxWifiRxBuff[0], ++idx); // Report("Data polled -------> "); idx = 0; } }

3. ON RM41L232 (Safety MCU - with no OS) it doesn't work and I'm losing Rx Frames, I tried it in both 2 ways like the above. (it just that I cannot multithread like with the CC3200)

Please help I'm stuck on it a long time now

kentindell commented 4 years ago

It sounds like you have a concurrency control problem: if interrupts get locked out for too long or tasks take to long to run then UART hardware buffers will lose bytes, and then of course frames will be dropped.

Have you tried a minimal system with no other interrupts and no locking out of interrupts? This might be hard if you have other software you don't have control over that locks out interrupts.

ArielSmarTap commented 4 years ago

Hi kentindell thanks for the reply. No, I haven't tried to run a minimal system yet, I will generate a new project with HalCoGen soon. How can I be sure that I'm having concurrency control problems?

I toggled pins on the RM41L232 in the main loop every x and y millisecond and tested the pulse with an oscilloscope to check for timing issues, but no issues were found.

Moreover, I developed a C# app to echo MIN frames from the MCU and found that is just the RM41L232 MCU Rx side frames that were being lost.

something that is worth to mention is that with the STM I don't get back MIN_ID = 0xFF ACK frames, it just receives the packets and executes what's on the min_applicartion_handler()

Do you have a tip? thanks