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.
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'm trying to establish Modbus RTU connection (for learning purposes) between two PC's (Win10). I'm using two USB to RS485 converters (D- connected together and D+ also connected together). This converters are connected to USB2.0 ports.
USB to RS485 converter
So I'm using "Modbus Poll" and "Modbus Slave" from "modbus tools".
First computer act as slave and has the following settings:
Slave configuration
Slave definition
Second computer act as master and has following settings:
Master configuration
Master definition
And my problem is, everytime i get "Timeout error":
Timeout error
So, what I'm doing wrong? I'm pretty sure converters are not damaged, because Win10 detecs them.
After all I just want to send simple value to another computer (via Modbus RTU) :)
Thanks
Well, this is not a real answer but I can provide some debugging suggestions.
In the past, I had problems with that RS-485 hardware you're using. It didn't work and I'm not sure why. The one I have uses a strange logic to drive DE pin of the MAX485. If I remember correctly, it inverts the TX line coming from CH340G using a NAND gate and feeds it to DE pin. I'm not sure if it was the problem, but I don't think it's a good design.
You may need pull-up and pull-down resistors on RS-485 lines to prevent it from floating when no driver is driving the bus. Some converters include them internally. Also, you may need 120 ohm termination resistors on both ends.
Instead of working with RS-485, you can simply use TTL logic for testing purposes. Use two USB-TTL converters, connect TX to RX (cross connection).
When debugging communication buses (USART, SPI, I2C etc.) always use logic analyzers. Even the cheapest one saves hours of debugging time.
you need to install proper drivers. I used following link which includes a how to video as well as download link for the drivers . Also disable RTS as its 2 wire RS485 so RTS cant be used.
I running freeRTOS and lwip 1.4.1 with the socket api in use on an stm32 processor (stm32f407).
Overall it works pretty fine.
I can send and receive data with udp and tcp.
But in a timewindow of 3 to 7 days I see a strange behavior.
My Problem
Every 3 to 7 days my client (Windows 10, which sends 1-2 HTTP-Requests per second) fails to send those requests. When this happens, there are ~10 Requests successively, which are failing. In very few moments, the stack won't regenerate at all.
My Guess
I think I have possibly missconfigured something in my LWIP config.
Because the stack is well used and shouldn't have any bugs in this direction
My Ethernet settings
server and client are directly connected, no switch,hub or router in between.
server (stm32/lwip):
static, 192.168.168.2
netmask, 255.255.255.0
client (win10) eth0:
static, 192.168.168.1
netmask, 255.255.255.0
client (win10) eth1:
dhcp, to normal working network
My Tries
At the moment I have tests running which are sending ~7-8 Requests per second, but the error doesn't apply more often.
I played around with the lwip config:
more memory for the stack
more pbufs
bigger pbufs
with/without backlog
But everything without improving of this connection problem.
Could it be because of the often reused port numbers from the client, which could make this problem?
Here I have the relevant part of the lwip debuging output:
tcp debugging output
https://pastebin.com/a9JabhET
Here the Wireshark log:
orig screenshot
hole wireshark log:
https://www.file-upload.net/download-12682664/debug_tcp_00001_20170828172950.html
And here my lwipopts.h:
lwip configuration:
https://pastebin.com/cW0v4hF6
It seems a memory problem, but as it is temporary, it could be a timeout on something.
I suggest to use the memory stats functions of LwIP, and also to enable the ARP debug messages.
I have a new Job and am no longer working on this issue.
Befor I stated my new job I could show that it was not a memory Problem on LwIP (I defined unreasonable large pbufs and memorypools) they never reached their limits.
The problem was in the DMA driver for the ETH. When once reached the memory chain end of the DMA driver the chain elements never got freed, so I run into RBU (Receive Buffer Underrun) problems and the RBU Flag never got reseted again and the DMA ETH driver was hanging in this RBU interrupt (even if there where enough LwIP buffs to write to from DMA chain). So I added a sledgehammer fix to the DMA driver and disabled the RBU interrupt (I am polling the RBU flag in multiple situations and clear it if needed, and start to read again from ETH).
I think since then the problem is more or less "solved". Not nice, but it worked.
I've got some information of my coworker at my old working place:
The RBU Interrupt and the clear did not work, because our used CAN stack did not work very well with FreeRTOS, the CAN stack used on busy systems much over 90% of CPU time, which let to the strange behaviour in ETH driver and LWIP.
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.
I am using STM32F205RGT6 Cortex-M3 microcontroller and coding with IAR Embedded Workbench.
I plan to keep the microcontroller in a power saving mode most of the time except when an external component tries to either communicate via SPI (the STM32 microcontroller is meant to be a SP slave) or via USB.
One external compinent is connected via SPI (PB12-15) and PC is connected via USB (PA11-12).
The communication works fine - I have tested both the SPI as well as USB.
I figured that once I am done setting up SPI and USB I will call a power saving function and add the same function call at the end of interrupt service routines. I have found PWR_EnterSTANDBYMode and PWR_EnterSTOPMode (in stm32f2xx_pwr.h) both of which I tried using.
However with such arrangement I cannot establish any communication (SPI or USB) with the microcontroller.
Is there something extra that needs to be configured (for example which pins should wake the microcontroller up)?
Am I using wrong function? Or wrong header file?
Can you point me to an example resembling such case (I could not find anything similar on ST's website)?
Any constructive feedback would be welcome.
In the mean time I found the application note AN3430 (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033348.pdf) which is somehow more digestible (only 38 pages) which gives an excellent overview on power saving in the microcontroller.
Since I don't have access to PA0-WKUP (the wake-up pin) I had to discard using stand-by. Seems that just a simple sleep mode in main loop - by calling __WMI(); - should lower current consumption enough in my case. I might consider stop mode if sleep mode isn't enough but I will have read fragments of datasheet on configuration of EXTI registers that the application notepoints to.