I am currently working on boot time diagnostic software for Beagle Board - xm it is just like POST ( power on self test ) what we have in BIOS systems , So as we know during early stage there is no driver present so that i came to know that i have to write a basic low level driver for the peripherals, but my question is what kind of test should be performed in boot time whether it is limited to basic read/write ( in case of my devices like i2c & spi) or i need to perform test for each and every functionality of the peripherals. So i just want to know what kind of tests are conducted or what kind of steps are followed for I2c & SPI during a boot time diagnosis .
Usually devices like I2C and SPI have default values of some registers according to their documentations. At boot time you can read from your diagnostic procedure all I2C/SPI peripheral devices and check obtained data. If you can read (default for reset or even better - read only constants) and determine they are correct, that means these parts are OK at this stage.
Related
For a project I just started working on, I need to write a firmware in C that lets me boot into two different firmware versions. The task is to be able to update a device which includes an STM in the field using the RS485 Port with an Intel .hex file. My idea was to place the two firmware versions at designated starting addresses in the flash, including some kind of checksum for data integrity. According to the flash module organization found in the reference manual, my first thought was to place one version into sector 10 (starting at 0x080C0000) and the other version into sector 11 (starting at 0x080E0000). After every reset, the STM32 should boot into a "bootmanager" which is just minimum code that decides, whether the firmware in sector 10 or sector 11 is the newer version. I want to clarify my idea in the following graphic:
[Rough process][1]
[1]: https://i.stack.imgur.com/xLowh.png
The 128kBytes of every sector are sufficient. So far, I was able to write Single Bytes into the Flash and read them afterwards. Also, I have already set up a working UART communication using the RS485.
My questions
Can I just write the .hex file into the Flash as it is without modification like
:020000040800F2
:1000000002200B
etc?
As I am unexperienced with with jumps: How should I perform the jump from the "bootmanager" into sector 5 firmware? Are the adresses automatically relative to the entry point in sector 5?
Can you give me keywords or tell me, what challenges I will encounter?
*EDIT: I'm aware that the STM itself contains a bootloader. Unluckily, the RS485 device is hardwired to the GPIO pins used by USART2. According to the reference manual, the internal bootloader can only be used by USART1 and USART3, CAN2 and USB OTG FS
Can I just write the .hex file into the Flash as it is without
modification like
no you cant. You need to modify the linker script to archive it
You need to have the whole both applications in the FLASH so divide it 50/50%.
I usually add some serial FLASH to have a copy of the firmware if both of the images are damaged.
Yuo need to write the custom bootloader.
Most of the STM32 microcontrollers have support for dual memory bank and on the fly update (cf AN4767 - On-the-fly firmware update for dual bank STM32 microcontrollers)
This will allow to perform exactly what you require.
Usually the microcontroller will need to have a bootloader and 2 banks for the image.
When booting the bootloader will start and check which version it would have to boot and set the start address accordinngly.
This application note is for the F7 series but you can check it to see how it could work for your specific microcontroller (cf AN4826 - STM32F7 Series Flash memory dual bank mode).
Regarding your questions:
The code would be written as usual but twice (or 2 different firmwares)
Look into the application notes referenced and keywords such as: dual bank, on-the-fly update, DFU, etc
How do I write to an SD Card using SPI with DMA available for the PSoC 5LP (32-bit Cortex-M3) chip?
I currently have a DMA and SPI tx/rx pair working, but for a different purpose so if the actual transmission is not an issue, I just don't know how to interact with the SDcard.
The datasheet for the PSoC 5LP is here.
Basic Info:
I am using the DMA in simple mode and the DMA TD chain is setup for:
8 bit width, 4 Byte bursts
auto complete the full TD (only needs initial HW request)
Loop back to beginning of initial TD when done and wait for HW request
The SPI Master is initialized in a gui, I have it set using a 16Mhz clock, 8 bit tx/rx transfers with a 4 Byte tx/rx buffer. interrupts are set on rx FIFO full, connected to them is an rx DMA.
The pointers for the SDcard SPI rx/tx are SPIM_RX_PTR and SPIM_TX_PTR respectively. The DMA transfers to and from them. The Arrays that I am transferring from and to are SDcardout and SDcardin.
Having SPI communication will only get you the lowest command/block level access to the card; you will need a file system. SD cards come pre-formatted as FAT32, so a FAT file-system will provide the greatest comparability, is not the greatest reliability (corruption is likely if write is interrupted by power loss or reset for example). It also has the advantage of being relatively simple to implement and requires few resources.
There are several commercial and open-source FAT filesystems libraries available. I suggest that you look at ELM FatFs or ELM Petit FatFs both have permissive licences and are well documented. In each case you simply need to implement the disk I/O stubs to map them to your SPI driver. There are plenty of examples, documentation and application notes on the site to help you. You can start with an SPI SD implementation example for another target and adapt it to your driver (or adapt your driver perhaps). Other FAT filesystem libraries are broadly similar to this and require I/O layer implementation.
The diskio layer of ELM FatFs is not media specific, so you in fact need an additional MMC/SD layer between that and the SPI driver. It is unlikely that you will find an example for your specific target, but it is possible to work from examples for other targets since MMC/SD over SPI itself is not target specific, the hardware dependencies come only at the SPI level and the GPIO implementation for the card-detect and write-protect (optional) signals. There are several examples for various ARM targets here, a project for PSoC support here (apparently a work-in-progress at time of writing).
I have done work on exactly this problem.
I found that the existing SPI module provided with the PSoC 5 components library is not ideally suited to bulk transfers to / from an SD card. As far as I could tell, it was necessary to clear SPI module flags in software on each byte transfer, rendering DMA much less useful. I think one solution is to use two TDs (Transfer descriptors) - one to perform the data transfer and a second to clear the RX flag after the first TD has completed - anyway, that's off topic.
I also found that the emFile component supplied in the components library is limited in its capabilities. I couldn't see any way to attach DMA, and even if I could, its clock speed appeared to be very poor. On top of this, emFile requires compile-time selection of FAT16 or FAT32, limiting your design to one or another filesystem only.
As I didn't like the idea of a more complicated DMA setup, I decided to design my own SPI component hardware in the UDB editor. The project containing the component can be found at: https://github.com/PolyVinalDistillate/NSDSPI
This incorporates the excellent FatFS library mentioned above (thanks ChaN), which takes care of FAT12, FAT16 and FAT32 formatted cards. As stated, without the filesystem layer, you will only be accessing raw data blocks of 512 bytes each. With FatFS, you get analogues of fopen(), fclose(), etc.
If you look at my component in PSoC Creator, you'll see it's actually composed of 2 components: One is the specialised UDB component implementing the main SPI logic, the other is a schematic connecting my UDB component to DMA and some control logic. This second component also has the API files containing my hardware-specific code and is the component to drop into your TopDesign schematic.
FatFS is included as a precompiled library, and LowLevelFilesys.h in the API folder provides access to all the file functions.
This component was designed with bulk-reads in mind and the API does the following for read:
Sets up a DMA TD of the required data length and tells my SPI component how many bytes will be transferred.
Triggers the transfer, causing my SPI component to send 0xFF automatically (no need to write 0xFF to the SPI for every byte received), while copying each received byte into the receive buffer via DMA.
Writing the card is performed in a more typical fashion, with the DMA simply sending data to the SPI module after preparing the SD card for it.
If you run my project on your PSoC system, it will perform a read / write test on the SD card, depositing a file reporting the specs:
Testing Speed
Writing 16000 bytes to file, non-DMA
Took 94 ms
Rate 1361 kbps
Reading 16000 bytes to file, non-DMA
Took 50 ms
Verifying... All Good! :D
Rate 2560 kbps
Writing 16000 bytes to file, DMA
Took 17 ms
Rate 7529 kbps
Reading 16000 bytes to file, DMA
Took 12 ms
Verifying... All Good! :D
Rate 10666 kbps
Some SD cards give better results, some give worse. I believe this is down to the SD card itself (e.g. class, usage, age of tech, etc).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What is the difference between the SPI and I²C protocols, used to program a microcontroller?
Please specify the pins used in each case.
SPI and I²C are bus protocols, and each is well defined:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
http://en.wikipedia.org/wiki/I2c
They are very similar in how they work, but they aren't the same and the differences aren't minor.
Depending on the microcontroller, they may have either, both, multiple of each, or none. They may share pins, and they might not. Refer to the datasheet of your microcontroller.
What is the difference between the SPI and I²C protocols
SPI is a 4-wire signalling scheme with a single bus master and several slaves. There's a chip select signal (CS, or slave select SS) dedicated clock signal (SCK) and two data signals, one for reception (MISO = Master In ← Slave Out), one for transmission (MOSI = Master Out → Slave In).
Transmission starts by asserting (= pulling low) SS, then for each bit MISO and MOSI are set after a SCK high→low transition and the actual transfer happens on a SCK low→high transition. Beyond that, there's no such thing as a "standard protocol" carried over SPI beyond the transmission of groups of bits; every component with an SPI interface may define its own.
I²C is a 2-wire signalling scheme, capable of multiple bus masters. It's a lot more complex than SPI, so I suggest you read the Wikipedia article about it.
used to program a microcontroller?
No, because that depends on the microcontroller you're using. Also do you want to write a program for that microcontroller that does communication over SPI or I²C? If this is the case I can give you no answer, because it depends on the controller you're using. It usually boils down to configuring the SPI peripheral (if it got one) or implementing the bit-banging on the GPIOs (which again is specific to the microcontroller used) yourself.
Or do you actually want to program the microcontroller flash over this? If the later is the case take note that the actual programming method depends on the actual microcontroller used and may not happen over SPI at all. And I know of no microcontroller that actually uses I²C for flash programming (except if it has been programmed with a bootloader that does the talking).
SPI is used for programming the Atmel ATMega microcontrollers. But the XMega microcontrollers are programmed using an interface called PDI, which is a completely different beast (uses the reset pin for clock and as a dedicated PDI Data pin).
Most ARM microcontrollers are programmed using JTAG. Then there are interfaces like SWI (which is related to, but not the same as JTAG).
SPI and I²C are defined, see Wikipedia.
Both are master and slave based and can share at least some of the bus. Both are serial based: I²C shares the data line so it is bidirectional, and SPI there is from master and to master. In both cases, these data lines are wired or (you drive zero or let it float and the pull up resistor pulls the line high). I²C is address based, and SPI has separate chip selects for each entity on the bus.
Your question needs work. Some devices can be programmed using SPI, but we generally talk about the microcontroller being the master and using these to program someone else. SPI and I²C busses are standards, but different vendors use them in ways to make it difficult to have a generic hardware interface. SPI more often than I²C will have hardware assist, but it is a good idea to learn to bit bang either and you can always fall back on that.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
I'm going to write an SPI driver for an ARM devlopment board. It is not used with Linux.
Yesterday, I read the QSPI driver that Xilinx provided and I tried it successfully. However, I would really like to write my own SPI driver.
Here are my questions:
What is the difference between QSPI and SPI on usage?
If I write a driver based on QSPI, will it work?
If I write a driver from scratch, what is the basic procedure (READ / WRITE / INITIALIZE)?
And finally, why must SPI send and receive at the same time?
Thanks everybody.
I think it may be easier to start with your last question first.
Why must SPI send and receive at the same time?
The easy answer is that it is part of the protocol. As data is shifted out on the MOSI line from the Master to the Slave, the data in the Slave's buffer is shifted to the Master on the MISO line. This allows the hardware to use a single register in each device for both the data being sent and the data being received. There is a good diagram of the process here:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
The not so easy answer is that SPI is not a well defined standard. There are different types of implementation depending on the devices you are using. There is even a variant where the MOSI and MISO lines are combined and used in a bi-directional manner (3-wire SPI). However, most of the implementations I have dealt with send and receive over two different lines and that tends to be the standard methodology.
What is the difference between QSPI and SPI on usage?
QSPI or Quad SPI actually does not adhere to the standard methodology and breaks the concept of sending and receiving at the same time. It utilizes four bi-directional I/O lines to send and receive data and is often used for memory applications (because it is faster than SPI). With QSPI you are not sending and receiving at the same time.
If I write a driver based on QSPI, will it work?
Certainly! You just have to familiarize yourself with the hardware that you are using. Again, SPI is very different from Quad SPI and you can often find hardware implementations that make it very easy to use QSPI. For example, your Zynq 7000 has a QSPI Controller that has a lot of features to simplify the coding process. It will also operate in a "legacy mode" that acts as a normal SPI controller. On top of that, the Zynq 7000 has two other standard SPI controllers that are not setup for QSPI. I would highly encourage you to read the technical documentation here:
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
If I write a driver from scratch, what is the basic procedure?
That is very hardware dependent. I did a quick overview of your hardware, but detailing the steps here would take far too long. However, the technical manual for your device appears to have great step-by-step instructions for configuring and using both the QSPI and SPI controllers. Here is an example from the SPI section:
17.3.1 Start-up Sequence
Example: Start-up Sequence
Reset controller: Assert and de-assert the Ref and CPU_1x resets, refer to section 17.4.1 Resets.
Program clocks: Program the SPI_Ref_Clk, refer to section 17.4.2 Clocks.
Tx/Rx signal routing: Refer to section 17.5 I/O Interfaces.
Controller configuration: Refer to section 17.3.2 Controller Configuration.
Interrupt configuration: Configure the ISR to handle the interrupt conditions. The simplest ISR
reads data from the RxFIFO and writes content to the TxFIFO. The PS interrupt controller is
described in Chapter 7, Interrupts. The interrupt mechanism for the SPI controller is described in
section 17.3.5 Interrupt Service Routine.
Start data transfers:
Master Mode operation select: Manual/Auto start and SS, refer to section 17.3.3 Master Mode Data Transfer.
Slave Mode operation, refer to section 17.3.4 Slave Mode Data Transfer.
I hope that helps!