I am trying to flash code over CANBUS on Nucleo-F446. I am referring this application notes
https://www.st.com/resource/en/application_note/cd00264321-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
So according to it in Boot mode the default baud rate of CAN is 125KBPS and we need to use PB5 and PB13 pin which are CAN2 pins.
For testing I tried to send CAN message with DLC=0 and STDID = 0x79 for which STM32 should return a ACK with same ID i.e. 0x79.
But I am not getting any response.
You must add a external clock to your Nucleo Board
The system clock is derived from the embedded internal high-speed RC for USARTx and
I2Cx bootloaders. This internal clock is also used for CAN and DFU (USB FS Device) but
only for the selection phase. An external clock multiple of 1 MHz (between 4 and 26 MHz) is
required for CAN and DFU bootloader execution after the selection phase.
STM Bootloader Description
Related
When connecting a Black Magic Probe to my mac i'm not able to receive any data when connecting UART RX to UART TX. I tried updating the firmware to the latest version without success.
I tried multiple Black Magic probes, both on Mac and Windows without success. The UART TX led on the board blinks when transmitting. I verified the connection was to the correct device endpoint (second interface of the device). When using an oscilloscoop I did not see and data transmitted on the TX output port.
By default the Black Magic Probe does not power the target. The Black Magic Probe uses levels shifters that require a reference voltage provided by the target to be present. Without this reference level the levels shifter buffer will not output any signals or receive any signals.
It is possible to use the 3.3V LDO on the Black Magic Probe as a reference by using this command in GDB: "monitor tpwr enable". Use the command: "monitor tpwr" to validate the target is powered by the Black Magic Probe. Please be careful the target supports 3.3V power and the total power consumption is limited. By supplying the power to the target the level shifters have a reference level and a UART loopback should work by connecting the RX and TX pin.
I'm using MPLAB X IDE to implement the transfer of UART data to I2C bus on dsPIC33EV128GM006 using interrupts. How should I start the data transfer if I'm not using the EEPROM or bridge converter IC?
For UART: Port PINS G6 and G7 are being used for communication.
FOR I2C: Port PINS SCL1 and SDA1 are being used for communication.
Baud rate: 9600
Crystal frequency = 32 MHz
The basic goal is to echo the signal from UART to I2C bus to know what data was sent or received on the UART bus.
Working part: UART is working fine with sending characters/strings. I2C is also working fine.
Please let me know the basic logic/approximate flow to implement the goal.
I have a third party device that is UART programmable.
I need to create a USB - UART bridge with a functional password (programming only after entering the correct password)
generated the code using the latest version of STM32CubeMX for Atollic TrueSTUDIO for STM32 9.3.0 ...
I transfer data between USB and UART through a buffer (one for usb-uart, and another one for uart-usb)
when I try to transfer several characters everything is OK, but when I try to transfer a large data packet, problems start due to the fact that the USB speed is much higher than the UART ...
there are two questions:
1.How do I tell USB that I need to stop transferring data and wait until the UART (buffer) is busy
2.How on the side of the microcontroller to get the baud rate set on the PC (set when the terminal is connected to the virtual COM port)
USB provides flow control. That's what you need to implement. A general introduction can be found here:
https://medium.com/#manuel.bl/usb-for-microcontrollers-part-4-handling-large-amounts-of-data-f577565c4c7d
Basically, the setup for the USB-to-UART direction should be:
Indicate that the code is ready to receive a USB packet
Receive a USB packet
Indicate that you are no longer ready to receive a USB packet
Transmit the data via UART
Start over
Step 0: Initial setup
Call USBD_CDC_SetRxBuffer to set the buffer for receiving the USB data. Unless you use several buffers to achieve higher throughput, a single call at the start of the program is sufficient.
Step 1: Ready to receive data
Call USBD_CDC_ReceivePacket. Other than what the name implies, this function indicates that the app is ready to receive data. It immediately returns before the data has actually been received.
Step 2: Receive a USB packet
You don't need to do anything here. It will happen automatically. Once it's complete, CDC_Itf_Receive will be called.
Step 3: Indicate that you are no longer ready to receive a USB packet
Nothing to do here. This happens automatically whenever a packet has been received (and double buffering is not enabled).
Step 4: Transmit the data via UART
I guess you know how to do this. It's up to you whether you want to do it in a blocking fashion or using DMA.
Since a callback is involved, you cannot put this code into the main loop. It might be possible to put all code into CDC_Itf_Receive if blocking UART is used. It would appear in the order 2, 3, 4, 1. Additionally, initialization is needed (0 and 1).
In the UART-to-USB direction, you would need to implement flow control on the UART. The USB flow control is managed by the host. Even though USB is much faster than UART, flow control is relevant as the application on the host can process data as slow as it likes to.
Regarding question 2: I'm not sure I understand it... The microcontroller cannot set the baud rate on the host. Either the host can specify a baud rate (transmitted over USB and applied to UART), or if the UART has a fixed baud rate, you can ignore baud rate (any baud rate set on the host side will work as it does not apply to USB).
I'm learning embedded development, and I'm trying to communicate with the accelerometer (LIS3DSH) on the discovery board using the SPI protocol. I'm only using CMSIS headers so that I'm forced to interact directly with the registers.
According to the schematics, these are the pins being used by the board for communication with the accelerometer:
PA5: SPI1_SCK
PA7: SPI1_MOSI
PA6: SPI1_MISO
PE3: CS_I2C/SPI
From my theoretical understanding of the SPI protocol, whenever I want to receive or transmit data between the master and the slave, I first need to pull the CS pin (PE3) down and then start the communication. This seems to be confirmed by the LIS3DSH user manual as well.
But now I'm confused about what the meaning of SSM is. According to the board's user manual, this is what the software slave management bit does:
When the SSM bit is set, the NSS pin input is replaced with the value from the SSI bit.
The NSS pin is nothing but the slave select pin, right? Which means it is PE3 in this case.
The SSI bit is bit 8 on the SPI_CR1 register. Does this mean I should instead toggle this SSI bit instead of PE3? That doesn't make sense because how would board know that the PE3 is the relevant CS pin?
So how are the CS pin/line and the SSM bit related, if at all?
If they're not related, do I need to configure the PE3 pin with alternate function mode and and as a pull-up, and then pull it low every time I need to communicate using SPI with the accelerometer?
The NSS pin is an input used as a CS by some other device when the SPI peripheral is in slave mode, or can be used as an output to support multi-master configurations.
If you are operating the SPI in single-master mode, the pin is not used at all.
Moreover SPI1_NSS is an alternate function of PA4 or PA15 so not related to the CS GPIO on PE3 in your case. In master mode, any number of available GPIO pins may be used as CS lines for each peripheral on the same SPI bus, and is driven in software - it is not an "alternate function", and not part of, or controlled by, the SPI peripheral.
I am working with ADE7953 metering IC and I use the uart serial communication in raspberry pi to communicate with the IC and i have wiring pi installed in it.Can anyone help me regarding how to configure the IC.
You need to check the datasheets and look for the MODE register configuration. Also take care for the active energy line cycle accumulation mode registers to set before you take IRMS or VRMS any of the ENERGY register
The ADE7953 contains a detection system that automatically
detects which of the three communication interfaces is being
used.
The CS pin (Pin 28) is used to determine whether the
communication method is SPI. The pin must be low
during the SPI communication for this interface method.
The CS pin is active low and will automatically lock onto
SPI communication as a result.
The SCLK pin (Pin 25) is used to determine whether the
communication method is I2
C or UART. If this pin is held
high, the communication interface is set to I
2
C; if it is held
low, the communication interface is set to UART.
Now, for UART should be configured in hardware as pin28 should be high, pin25 should be low, pin 27 Rx and pin 26 Tx