I have a SPI for MSP430 written. If I send WRSR(01h) or RDSR(05h) to M25P64 flash.
The response I get from the Flash SPI_MISO is FFh.
So my question is "Is the response I have obtained is it right?"
How do I come to an understanding that handshaking between my SPI and Flash is correct?
Thanks
AK
Is the response I have obtained is it right?
The response is wrong. 30 seconds on Google and in the datasheet will tell you that. Things to check (since you have not provided any information):
How do I come to an understanding that handshaking between my SPI and Flash is correct?
Is this a new piece of SPI code? If so have you checked with an oscilloscope to see what you send out (clock and MOSI) is what you expect and matches what the datasheet says the device expects? It's the definitive way to be sure.
Does your SPI code work with any other devices?
Are your IO pins configured correctly on the MSP430?
Have you got the SPI module configured correctly for phase and polarity?
Did you forget to assert the chip select line?
What about HOLD?
Did you remember to send a dummy byte after the RDSR command so that the device would send the status register value?
Do you see a response from the device on an oscilloscope? Does the MSP430 read that value or a different one?
You are sometimes better first of all trying to read the device ID rather than the status register for a new piece of code. The reason for that is the device ID will never change, whereas the status register might change (although that depends on the device).
Related
I'm working on a BMS project for an electric car. I'm using LTC6804-2 for voltage and temperature measurement in each cells. As a first step of development, I would like to establish a successful communication with the monitoring IC (LTC6804-2). So, I'm sending set config register command and trying to read back the config register values that I have written. If I receive the configuration register values without a CRC error, I consider my communication as successful.
In my case, I do not receive expected register values with proper CRC when I read back. Let me break down my situation into small segments.
I'm working on a custom BMS board for this project(LTC6804-2 and STM32F072). I will attach the schematics below. To test my code, I tested my program with DC1942C demo board and arduino UNO. And it is working fine. I can read back the config register and I can calculate the cell voltage and Auxiliary values.
When I try to implement the same program in my custom BMS board, I'm not getting the correct values. I always get CRC error in the received data.
Following the guidelines from the Analog Devices forum, I tested the Vref2 value after sending the config register command, and the voltage goes up to ~3V as expected. So the IC is receiving the message properly. But Why it is not transmitting back?
Below are the captures from the demo board and BMS custom board.
Register read capture from Arduino Uno and demo board DC1942C
Register read capture from the custom board
In fact I tested the program with STM32 development board and DC1942 demo board, I get the correct values.
Thank you for your help. If you want any additional details, please let me know.
LTC6810-2 datasheet
I'm going through the process of coding up an xHC interface following the Intel xHCI guide. I'm at the point where I need to give the controller the memory buffer address for the command ring (using the CRCR_LO and CRCR_HI registers).
However, after I write these values, I am not able to read it back to verify. The documentation indicates that the value will be updated after the next doorbell, but that doesn't seem to happen either.
I do see the CRR bit go high (command ring running), so it's at least doing something. But I am also not getting command responses in my event ring (though I am getting port status change messages in the event ring).
Can someone clarify how this register works? Is there a way to verify that command ring buffer address?
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).
Can anyone please explain how to establish a communication between stm32 dev board and gps module? I am not knowing how to send AT commands to gps module through MC through a source file through UART. Please clarify me in this aspect.
There is a lot of literature on STM32 and UARTs on the web. If I were you I would download the STM32CubeMX. This program generates most of the code for you. You select your processor (or development board), select the clocks and peripherals, and click Generate Code. It also comes with very handy example projects, and might even have a complete project with a working UART that you can put straight onto your board.
And I would first make sure my UART is fully working before connecting the GPS. This you can do by trying to echo. Connect your TX and RX pins with a wire. Then, everything you transmit you will receive as well. It's a easy test to see if everything is working.
I would also work through the TrueStudio IDE. It basically works plug and play
If you use the ublox module, you must use a serial port to communicate.
You have to connect RXD(ublox) to TXD(micro) and TXD(Ublox) to RXD(micro) ,
and config your StmCubemx like This :
http://wiki.sunfounder.cc/index.php?title=Ublox_NEO-6M_GPS_Module
Config Stm32 :
[Step 1: https://i.stack.imgur.com/1B4Ed.jpg ]
[Step 2: https://i.stack.imgur.com/6ULOm.jpg]
[Step 3: https://i.stack.imgur.com/GD0VL.jpg]
If you have another question, please ask
First of all, I think you should test AT command with module sim through (USB to UART) to PC in order to understand procedure operation, such as: module sim - TCP/IP - thingspeak server. The next time, you can refer this link for code: https://bitbucket.org/mbari_peter/sim800-mqtt-ravi/src/78e36076c89b4618cf57a538f0c70f91b2b876dd/modemDrivers.ino?at=master&fileviewer=file-view-default
If you have any questions or encounter any problems, you can ask! Thanks for reading!
Typically, GPS sends data # 1 Hz after starting up. You just need to capture this NMEA sentences and filter the receive buffer according to your requirement.
Try using UART receive interrupt. Make sure the baud rate of both GPS module and STM32 are same.
I've got a sim connected to my microcontroller. The rst, i/o, and clck pins are wired correctly. There is a hardware UART on my board, but since it is full-duplex and not half, I've jumperd RX/TX together.
So far, I toggle RST according to ISO-7816, and my UART buffer fills up with the ATR the sim card responds with. Once I've received the ATR, I change the UART to TX mode and send it a PPS. After sending, I change the UART back to RX only mode. It follows the correct format as stated in ISO-7816, but I do not receive the confirmation bytes from the sim. The confirmation is supposed to be a repeat of the settings I sent.
I suppose your problem is of the same origin as I had with gsm modems.
Sending a command you get an acknowledgement from the device, then send the next command, get ack, etc, etc. Soon or later the device hangs up.
The key is the interpretation of the acknowledgement.
You may think the acknowledgement means the command is accepted AND executed. However - at least at ALL gsm modems I know - it means no more but the command was accepted and INTERPRETED - but not executed. In case of time consuming commands you send your next command during previous command is being executed. You do it because you may think acknowledgement means the command is done - but it is not true.
The device may or may not buffering cumulative commands, but soon or later the device runs out of resources and hangs up.
I have no experience with device you use but the phenomena seems to be the same.
While I'm not a protocol expert, the most likely cause seems to me, that you send PPS too early- "after sending" can be easily too early on modern microcontrollers. ISO 7816-3 states, that the guard time applies as usual and the waiting time is 9600 etu's.
Sending PPS too early means, that the card does not yet listen, which perfectly explains receiving no response at all. Wrong format would cause an error block, which should also be visible on the scope, which supports my assumption.