I have an uart managed by dma rx channel.
In order to disable the error callback when a framing error comes (HAL_UART_ERROR_FE) I have comment out the line of code
huart->ErrorCode |= HAL_UART_ERROR_FE;
Is there a grace way to do that, without to edit the HAL libraries?
Related
Writing a simple UART program using CubeIDE 1.7.0 for a Nucleo-H723ZG board using DMA. A UART DMA receive call is issued waiting for input from a serial port app on the Mac OSX host (CoolTerm). A callback echoes the data received.
When a text message is sent to the board nothing but zeros is echoed back.
I noted that CubeMX had generated the DMΑ initialisation call (MX_DMA_Init()) AFTER the UART initialisation call (MX_USARTx_UART_Init()).
By Reversing the sequence of these two calls the code worked perfectly!
Is this my error, has something been missed in the setup, or is it an MX error?
This issue only affects CubeIDE 1.7.0 users on MacOSX Big Sur. Under Windows there is no problem and the code generator correctly positions the DMA initialisation call before that of the USART.
When using the MX configurator the peripheral initialisation calls are generated in the sequence in which they are entered. When setting up a USART to use DMA to perform the data transfer, two peripherals' initialisations need to be generated: the USART and the DMA device. As the USART was the first of the two peripherals selected the USART init call is generated before the DMA init call.
However, unknown to me at the time, the USART needs to set up a DMA register which must have its clock enabled. The DMA init must therefore be done BEFORE the USART init. Hence my problem.
Knowing this, in the MX Project Manager tab, the Advanced Settings tab provides the option to rearrange the sequence of these init calls and all is well!
So this is a bug. However, using a Nucleo-H743ZI2 with USART DMA there is no problem with out-of-sequence initialisation. Thus far the bug is limited to the Nucleo-H723ZG!
The firmware generated by CubeMX6.3.0 for Nucleo-G474RE does the same initialization inversion (UART before DMA) and leads to unresponsive code.
I am using STM32F767ZI nucleo board. I have configured SPI with 750kBits/sec. I have tested the hardware connections for max31856 and they are good. I ran a mBed code to test the Max31856 and it works well and sends the correct temperature. But I am not able to replicate that with HAL libraries - STM32CubeIDE alone with Max31856.
I am sending 0xFD to CR0 address and I am receiving 0x7e. I am sending 0x04 to CR1 address and I am receiving 0x02. I feel I am seeing a missing bit - LSB while receiving it or while sending it. I am not sure where the missing bit happens. I have tested with 0x08 and I get back 0x04. It looks like a clock or timing issue in my code. My code below.
https://gist.github.com/jayaram12391/31e060bd7fb97092cc3bf4eddcb7dadf
Any suggestions appreciated.
In order to freeze a timer during a break in debug mode on a STM32H7, one has to set a bit in the DBGMCU. But I didn't find such a bit for SPI. Does it mean that the SPI is always frozen ? Or on the contrary never frozen ?
Short answer:
There is no such option for the SPI. SPI is always enabled, if used and proper configured.
Long answer:
There is no such option for SPI because this interface must be either actively served by the microcontroller. In this case the SPI transaction is automaticly stoped if your device is halted e.g in break mode. Any ongoing transaction of a word/fifo will be executed anyway.
Or the dma controler is configured to server the SPI. In this case data transmission is controlled by the dma controller. The dma controller itself has different trigger sources. As long this trigger source is not a timer depended one there is no way to implicitly halt the transfer.
See also: https://stackoverflow.com/a/43225545/5388805
I am automotive software engineer.
I use vector Canoe tool to simulation can network.
For example, at Ecu sleep status in vehicle, I transmitted general message to Ecu having IG Block function in Canoe. After that, Ecu was wake up.but tx error frame generated. I saw Error frame information. It was message's id I sent. And, after 1ms time, message of same Id transmitted in canoe. I guess can controller may transmit error frame because of message to send uses IG Block. And I think that Can controller should not receive message. And I think IG block message was lost.But in Canoe display, seems to transmit error frame and normal message. Is it true? Can controller know whather or not Normal message ?
And can controller receive that message?
enter image description here
In your screenshot, you can see, that the error frame is caused by a bit error.
Bit error means, that the message observed on the bus during sending did not match the message sent. It is a Tx error, i.e. the sender itself detects and alerts the error, and will try again.
Bit errors are caused mostly by wiring problems, e.g. wires too long for the used baud rate, bus not terminated correctly, etc.
It may also be that the baudrate is not setup correctly.
I hope that helps you to find the root cause.
I am using ‘SH72867(Renesas)’ connect with ‘EEPROM(24LC04B)’ . In the customer’s document at ‘address 0xF0 of EEPROM have data 0x5555’, But when I reading from this address always return ‘0xFFFF’ and same with other address.
I can’t write to EEPROM too.
I used I2C sample of Renesas but not run.
Do you have any suggestion about setting up I2C?
Sorry for my bad English and no clear explanation.
Any help apprciated,
Thanks
Verify the common issues:
Data and clock are connected properly.
Pull up resistor on clock and data connected to VCC.
Loop the I2C read request, connect scope and verify that I2C signals are OK. In addition check the ACK bit.
Verify clock is lower then 400kHz.
When using code examples, they usually fit to specific board. Verify that the code example configuration is the same as your board.
Some MCU may have more then one I2C pinout options. The code example might use I2C module that connected to diffrent pins.