I am using stm32f429i Discovery board to interface SST26VF064B (Memory) over SPI communication protocol. I did all the connection and use the following HAL libraries code to read its identity register(0X9F), status register(0X35):
HAL_GPIO_WritePin(GPIOC,GPIO_PIN_2,GPIO_PIN_RESET);
spitxbuf[0]=0X9F|0X80;
HAL_SPI_Transmit(&hspi2,spitxbuf,1,50);
HAL_SPI_Receive(&hspi2,spirxbuf,1,50);
HAL_GPIO_WritePin(GPIOC,GPIO_PIN_2,GPIO_PIN_SET);
I am receiving 00 as the response. What am I doing wrong? I used the same configuration code (using SPI5) to read the on board Accelerometer. It worked, but with the external memory it is not working.
Related
My doubt is regarding the physical layer of the communication, I know from practice that for using for example teraterm to communicate with a MCU is simply enabling and configuring an UART peripheral, and then connect via USB the microcontroller and voila.
But it doesnt make sense to me yet that if USB connects to DN and DP, and an UART uses RX and TX, how does the host effectively communicates to the microcontroller?
There are two possibilities.
You connect to a USB/UART bridge such as devices made by FTDI or Prolific,
The microcontroller has a USB device controller and USB stack implementing the CDC/ACM device class (virtual COM port).
In the first instance, the bridge chip presents the CDC/ACM device to the host and exchanges data with a UART connected to the microcontroller UART. I/O control such as setting the baud rate have no impact on the USB connection, rather they are used to configure the UART link.
In the bridge arrangement, the bridge chip may be on the micro board, or it may be in a USB/serial adapter cable. Moreover internally the bridge chip is a microcontroller with a CDC/ACM device stack.
Unlike say RS-232, USB is not a peer-to-peer full duplex connection, and is not merely an electrical connection; USB requires quite complex device and host controllers and is more analogous to a device bus such as PCI than it is to UART serial connections. A CDC/ACM class device conforms to a specific protocol to allow a "virtual" UART to appear at the host. The UART you see at the PC is emulated, and is not physically the UART in the bridge.
The physical actual USB connection is a master-slave connection, with data and I/O control commands (such as baud rate and flow control) sent in USB packets to be unpacked, interpreted and transferred to the application layer via the CDC/ACM USB stack. In this arrangement the device, acting as a slave cannot initiate an exchange; rather the host continuously polls the device to which the device may return a packet containing its "tx" data. The polling and data rate of USB are fast enough to allow the simplex master-slave exchange to emulate a full-duplex UART connection, at higher throughput than can normally be achieved by a typical real UART, and certainly faster than a physical RS-xxx connection.
You can get an idea of how all this works by observing the raw USB data exchange using a tool such as WireShark. You will see that a lot more than just your application "serial" data is being exchanged.
You need to use a uart-usb interface IC that can convert uart to usb (and vice versa).
I am working on a project which contains acquisition of ECG data with the ADS1293EVM. MSP430F5529 is part of this board as well. For the communication between analog part of the board and microcontroller, I am using SPI and there is also FET Debugger from TI to program the microcontroller. Now I am printing data using printf to a terminal I/O which is part of the IAR software.
However, I would like to print ECG data to the terminal app in PC or to LabView, not in Terminal I/O in IAR software. The board is connected to the PC by USB so there is UART port in device manager. Is there any possibility?
Yes it is possible. You can push all the data on UART which is used in communication between PCB and PC. Than you can use any serial monitor for getting data displayed.
The only connection between your board and the PC is USB, so you have to implement a virtual USB COM port (CDC). TI's USB stack implements such an interface.
Context
I have accidentally uploaded some ARM Cortex M0-cmis files (core-cmFunc.h and core_cmInstr.h) to the STM32F407VG discovery board. After I noticed my mistake, I tried to undo it by changing my code and upload it again... but it said it couldn't make connection.
What I already tried
I've tried to get passed the USART interface of the discovery board by uploading the code directly on the ARM Coretex M4 chip via the bootloader. I connected BOOT0 to VDD and PB2(=BOOT1) to GND so the chip starts up in the Pattern1-mode. Then I connected PA9(=Tx) and PA10(=Rx) to an USB to TTL cable (by the use of a RS-232 chip in the cable) and reset the device. I started the "Flash Loader Demonstrator" from ST to make connection with the board (I've done this before and it worked). But that didn't made connection either.
Extra information
The Windows filemanager "sees" the ARM Cortex M4 file when it gets connected to the PC;
Led LD7 emits green light when the board is powered;
Led LD1 emits red light;
Does someone knows how I can factory-reset the flashmemmory of the STM32F4 so it acts at it should again?
After some trial and error I've come to the conclusion that I accidentally activated the OTG_VBUS with my code. I couldn't upload another code because that bus was active on PA9(TX of USART2). It seems that the VBUS was held active, even in bootloader mode.
PA9 connected to VBUS
The solution to this problem was the use of another bootloader interface, I used USART3 on PB10/11, but you could also use PC10/11. After I uploaded a dummy code in that manner, I
was able to upload codes with the Coocox-IDE again.
Other Bootloader interfaces
I have LPC2148 daughter board but I am not able to dump/burn code into it, and it doesn't have any usb connector to dump code.
I read on internet by using FT232RL I can able dump code into LPC2148 but I am not able to do so.
please give me solution
thank you..!
The chip supports In-System Programming (ISP) via an on-chip boot loader ROM.
From the User Manual UM10139:
Programming of the Flash memory may be accomplished in several ways:
over the serial built-in JTAG interface, using In System Programming
(ISP) and UART0, or by means of In Application Programming (IAP)
capabilities.
The function of the FT232RL you mentioned is to act as a USB/UART bridge and is necessary primarily because modern PCs lack legacy RS-232 serial ports. You can in fact purchase a USB-Serial cable or adapter which will contain a bridge chip such as the FT232RL. Most of these use RS-232 line level signals, so you would still need an RS-232 line driver/receiver to connect then to your board (if your board has a serial port, it probably already has a line transceiver and you can connect directly to that). It is possible from specialist suppliers including FTDI themselves to get a USB cable with integrated FT232 and bare TTL level connections to connect directly to LPC2148 UART0 Rx/Tx lines.
If your board does not already expose a UART0 serial port and the necessart control to start the boot loader, a Serial Port Bootloader Interface board is available. For that you may then also need a USB/Serial adapter or a PC with a legacy serial ports.
Once you have a suitable serial connection, you will need the LPC2000 Flash Utility software to run on the PC.
The JTAG option is however faster, and more powerful since the JTAG is both a programming and debugging port. With a suitable toolchain and JTAG adapter it is possible to program and execute code with source-level PC hosted debugging including break pointing, data watching and single stepping of the code.
My question is going to be rather vague but I will try to explain as detailed as I can what I am trying to resolve.
Trying to learn Linux kernel USB stack I have started to think of making a simple USB driver for my Atmel evaluation board based on ARM M0+ MCU to run away from Windows tools (Visual Studio plugin).
I have spent few days learning kernel's USB API and come to conclusion of how to make this. My driver aims to make my board connected to PC through USB cable act like a simple USB flash drive. Making that I then can easily program it with a new version of firmware written by me.
I have found that I need to find out specific interface (I am talking about interface in terms of USB specification, not interface we used to use as a code abstraction) that holds an endpoint (pipe) responsible for interaction with flash memory. And then I can map it to character device and interact with it using standard I/O operations that are described in struct file_operations structure.
Simply using cat on /proc/* file descriptor that was created by USB Core subsystem I have investigated that interface responsible for interaction with flash memory holds bulk endpoint (likewise, this terms come from USB specification, CMIIAW) that act as a "descriptor". Linux kernel USB Core subsystem gives neat interfaces to talk to different kind of endpoints whether it control, interrupt, bulk or asynchronous endpoint.
Now I have come closer to my very question.
Also the main transfer unit in communication between two USB devices is abstraction called urb - you allocate it, you fill it, you send it to USB Core subsystem, you read it if it was IN type of urb and, finally, you free it. What is confusing for me and tightly related to my question is the next API include/linux/usb.h:
static inline void usb_fill_bulk_urb(struct urb *urb,
struct usb_device *dev,
unsigned int pipe,
void *transfer_buffer,
int buffer_length,
usb_complete_t complete_fn,
void *context)
Assume I have obtained an information from board's datasheet about where to write a program code. Let's say, we have 0x00100 - 0x10000 memory region. I will compile my code, obtain a binary and then using standard Linux tools or writing a simple user-space wrapper application I will use lseek to set file's offset to 0x00100 and write system call provided with a buffer (binary compiled previously) and it's length.
In kernel space, I will have to allocate urb in write system call handler, fill it with a buffer sent from user space and submit this urb to USB Core.
BUT I can not find a way how to specify an OFFSET set earlier by lseek. Do I miss something? Maybe I missed some concepts or, perhaps, I am watching in a wrong way?
When your embedded Linux device acts as a USB mass storage device, the flash as a peripheral on Linux device is unmounted, and the gadget driver is loaded. Linux then loses control to the flash, and now the PC connected to your Linux device fully controls the flash. This is because a flash as a USB device can only has one USb host.
The gadget driver works purely in kernel space. It does not receive or transmit data from/to user space. It calls vfs_read() and vfs_write() to access the files on the flash, with an field offset. The offset is got from the USB commands sent from your host - Windows PC.
There is no way to specify offset using USB subsystem's API. I misunderstood whole conception of USB as communication protocol, unwise me. You must first learn underlying protocol your device uses to communicate with others.
If your device acts as a USB HID device then learning specification of how to exchange data with USB HID device is the way to go. If there is something proprietary then you can do nothing but reverse engineer it (listening USB packets with a sniffer on system where a driver for your device exists).
As for my board it has embedded debugger that serves as a communication module besides being debugger itself. Specifically, my device is equipped with EDBG and here is a link on description of protocol it uses for communication.