HAL - Interupt-driven I2C, USART

[darkridge]

Hi,

I am new to the STM32 world and currently working on the following application on a STM32F103CBT6 @72MHz:

1. Collect data from I2C sensor triggered from external interrupt @800Hz
2. Read commands (MODBUS RTU) from USART and respond.

I set up the uC with STM32CubeMX.

ISR for Task 1 is simply:

 

 HAL_I2C_Mem_Read_IT (adxl343_i2c_handle, adxl343_i2c_addr<<1,ADXL343_ACCEL_ZOUT_REG,1, d, 2);

 

I do not even bother doing anything with the data in uint8_t d[2].

ISR for Task 2, HAL_UART_RxCpltCallback() is:

 

modb_rx_buff_head = (modb_rx_buff_head+1)%MODB_RX_BUFF_SIZE;
HAL_UART_Receive_IT(&huart2, &(modb_rx_buff[modb_rx_buff_head]), 1);

 

ISR for Task 2, HAL_UART_TxCpltCallback() is:

 

// Clear the TX_EN pin on the RS485 interface IC
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_RESET);

 

There are no common variables between both tasks.

Task 1 alone works perfectly (checked w/ oscrilloscope).
Task 2 alone works perfectly .

Task1 + Task2 : uC hangs (either immediately or after a short time)

I tried playing with Interrupt priorities to no avail.

The ISR's are really short. I run the same setup on a 8MHz ATMega328 without problems.

Here are my questions:

1. Can anybody point me to where to start looking for malfunction(s)?

2. Is it worth digging into the HAL stuff? (I have read much discouraging posts on that topic and have not seen a single comparable working example.)

3. If the answer to question 2. is 'no' then should I use the LL/CMSIS stuff or rather go directly down to the registers? (Please, keep i mind that I am new to STM32.)

Any help is appreciated.

 

[darkridge]

Okay, I found one issue: It was a local variable issue. So far, it looks much better.

[Pavel A.]

> uC hangs 

Is this an endless loop in error or fault handler? Break with the debugger or instrument the error handler(s).

>  Collect data from I2C sensor triggered from external interrupt @800Hz 

Read I2C device almost every ms, from an interrupt handler? won't call this a robust design... but check the above first.

> should I use the LL/CMSIS stuff or rather go directly down to the registers?

Not yet.

 

 

[darkridge]

@Pavel A.:

Thanks for your quick reply!

> Break with the debugger or instrument the error handler(s)

Okay, I will have to figure out how this is done. Last time I used a debugger was for Turbo Pascal on Windows 3.1 :)

> Read I2C device almost every ms, from an interrupt handler? won't call this a robust design...

Why? The sensor gives me a trigger when data is ready and I sample. I would not even be aware of another viable approach for this. Both the ISR and the callback function are very small. Just one function call when the sensor triggers and putting the data into a buffer in the I2C callback. From my experience, even for much slower uC's this is a most boring task, given that the there is no hidden polling in the interrupt-driven I2C functions. Am I missing something?

> LL/CMSIS - Not yet.

Okay, I will try to stick with the HAL for as long as possible. Infact, after fixing the local variable issue, things seem run smoothly.

 

[Karl Yamashita]

---

Okay, I will have to figure out how this is done. Last time I used a debugger was for Turbo Pascal on Windows 3.1

---

Wow, that's a long time ago. I still have my debugger from back then 

 

[Pavel A.]

>Last time I used a debugger was for Turbo Pascal on Windows 3.1

That sounds scary.