min-protocol / min

The MIN protocol specification and reference implementation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

ArielSmarTap opened this issue · comments

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

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.

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