Android Things SPI Burst Length NXP i.MX7D - spi

I'm using the NXP i.MX7D with Android Things to read images from a camera via SPI. The image is broken down into packets of 244 bytes but it appears that the Android Things drivers only handle bursts of 64 bytes before the CS and CLK are deasserted for a period of time. The problem is that this invalidates the packet.
To change this behavior, I can toggle the BURST_LENGTH field in the ECSPI_CONREG register. I do not think I have the ability to change a register through Android Things but I think I can using the NDK and a C program. If I make this change will the Android Things SPI driver work as is or will I have to craft my own in C?

Related

How does JTAG flash memory programming work?

I am currently using Xilinx ZCU106 board, and I am curious about How does JTAG support flash memory programming. I can upload the boot images or hardware logic just by connecting JTAG USB cable to USB connector at the ZCU106 Board, and press the flash button on the host PC. By doing this it looks like the QSPI Flash holds the boot images or hardware logic image and the system initializes itself by using this image. It seems like a magic, and I want to know about the detail.
So far I understood is that I can access JTAG interface via USB cable (thanks to the FTDI chip?), and JTAG boundary-scans the devices connected to it.
However the problem is here, I couldn't find the link between JTAG and QSPI Flash (MT25QU512ABB8ESF-0SIT). I searched several references, including manual of QSPI Flash (MT25QU512ABB8ESF-0SIT, https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_u_512_abb_0.pdf) but there seems no port for JTAG (such as TDI, TDO, and TCK), but only SPI.
So the first assumption, I thought on the JTAG chain maybe there is a SPI controller to flash the memory. However I couldn't find any clue on the references that I've read so far that a SPI controller exists on the chain or even a SPI controller that controls the QSPI flash really exists. And the second assumption, I thought PS- ARM Cortex A53- TAP (?) does the magic. PS TAP receives JTAG signal and processes the JTAG command. To be precise, let's say about flash memory programming case, then there is like a JTAG command for write data on the flash memory via SPI.
Among these two, I wonder if there is the answer. One thing for the last, if the second one suppose to be the answer, then the processor (Cortex A53) should implement the functionalities by hardware logic to parse Flash write/erase command signal from JTAG interface and let the SPI controller that the system includes perform the write/erase job? Somewhere I read that the JTAG itself supports writing data on the Flash memory but everything I could find was just TDI, TCK, TDO, TMS, and TRST ports which does not fit in any port of QSPI Flash.
Probably I am confusing a lot of concepts very much, but I want to know about the exact mechanism behind the scene on JTAG flash memory programming.
Normally, it will do with the following sequence:
Send some software to target processor in RAM
Send data to target processor (in RAM)
Trigger execute command to store data into the flash memory.
Now the expected data are available in flash memory.

ST-LINK could not connect to the target

I'm trying to connect to stm32f401rbt6 with st-link utility.
The MCU has 6 pins connected, as on the image below.
The target is powered by a lab power supply, target GND is connected to the ST-Link GND
When I plug it to the computer, st-link utility says it can't connect.
Tried:
Update ST-Link firmware
Connect under reset is by default, tried all available methods
Checked connectivity for the pins on the image
Connected with the same ST-Link to other MCU
Desoldered the MCU and soldered another one
The issue is still remain. Please suggest what I'm doing wrong, or how to check that my MCU is alive.
I once had similiar issues and i figuered out, that decoupling capacitors were vital. After soldering this onto the pcb, it worked like a charm.
(Similar question: Stm32CubeProgrammer not connecting (no error msg) using ST-LINK V2 dongle and Lora E5 mini board)
You can try the following suggestions. Some ST devices are a lot more sensitive than others when it comes to programming. I have had some ST devices programming without issues and then using practically the same setup on other devices it just won't work.
Place a 22ohm resistor in series on the SWDIO and SWCLK lines. This link suggests only placing it on the SWDIO line but I found that I needed it on the SWCLK line as well. Typical SWD Circuit
For the ST Link Settings try using these:
Reduce the frequency from 4MHz to a lower frequency
Use SWD
Use connect under reset
Don't use an external pull-up on the NRST line.
Make sure that your programming wires between the ST-LINK and the target board are as short as is conveniently possible.
(This one I must stress as being important) Make sure that your processor's ground pins are all connected very closely together (i.e. the tracks between them are as short as possible) and that very importantly your programmer ground is also connected to the same ground pins very closely.- At high programming speeds a thin or long unbalanced (different length) ground track to the processor can cause a problem with some devices.
Whatever you are using to supply power to the processor must have a supply with a similar voltage as the ST-LINK (mine is 3V) - (although I have found that if the processor supply is 3.3V programming seems to still work most of the time.) (Remember the original ST-Link does not supply power only reads the power level.)
A dodgy programming setup can accidentally set the protection to LEVEL 2 bricking your device - so if you have been trying and not getting any further, it might be time to replace your IC.
Prior to changing / erasing a device that had been programmed to LEVEL 1, you might need to first enable the PCROP_RDP option byte. - Once enabled, you should be able to change from LEVEL 1 to LEVEL 0 that will automatically erase the device.
Some people have suggested holding the device in reset until just after pressing the erase button to enable erasing it.
I hope these suggestions help...

how the usb spi flashing device write program to atmega?

the atmega microcontrollers have the internal programmable memory.So the usb flash device write data to internal memory of atmega through spi or it store the program and works as slave?i also want to know can the atmega get program,file in the MicroSD and run without internal memory or it need to run a program in internal disk then including the program in MicroSD?i don't know how the process work in atmega microcontroller.
There are several ways to program the AVR:
Using an external programmer. The Chip is in reset state during this. Then the programmer uses special a special protocol to directly write to the flash inside the controller. This is how your USB programming device probably writes code to the AVR. There are several protocols for this, but the most common one uses the same pins that are used by SPI. You should not confuse them just because of that ;-).
The controller writes the program itself. The chip is actively executing a program. That program on the chip fetches the instructions from e.g. a sd card and using the SPM instruction to copy it to local flash.
The AVR can only fetch instructions from it's own flash memory - you cannot execute directly from RAM or from any other external source.
The best answer for this question you can find at the end or middle of datasheet for AVR device (eg ATMEGA 328P-PU). If you are using some flashing device connected with computer, there is some initialization sequence after start and then there are send some 4 Bytes commands that tels microcontrolers, where to store values to flash and/or eeprom, fuse bits, or cares about erasing etc. There is also posible to read ID of chip.
Atmega microcontroler can be also programmed in paralel mode, where are some bits used for sending commands that tels, what to do with data on data bit.
If you ask about downloading program from SD card or any other device, there is possible to write to the flash through SPM, as there was told above. Some devices do not have part of flash for downloader - if I remember ATMEGA 48, and devices, that have configurable part of memory usable also for downloader, that can handle this, eg. ATMEGA 88, 168, 328. So if you want to download program from SPI, USART, TWI, etc, you need to configure fuse bits and create downloader that will do it for you. I am not sure, how ATMEGA 48 do this, but there si probably possible to write whole flash by SPM instruction.
However the best answer you can find in the datasheet. On pages folowing 255 you can find further information. http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf

Obtaining a fast ADC sample rate in embedded linux with an external ADC

I've been given the task of getting ADC samples onto an embedded linux computer at the highest rate I can (up to about 300kSPS). I am playing with several different platforms (odroid, edison) but easrly on I realized the limitations of using the build in ADCs from within linux and timing (I am relativly new to this).
Right now I am reliably getting 150kSPS using a teensy 3.2 with a very basic swapping buffer, a PDB, and the USB connection. USB writes take 2.5usec no matter my buffer size so any faster and the ADC read interrupt collides with the USB and I get nothing.
My question is: Would using an external ADC chip enable faster speeds? I see chips on Digikey and Mouser advertising 600kSPS and higher with SPI and even parallel outputs... but I fell like the bottleneck is the teensy with USB writes. Even if it could (and I am sure it could) read values 600k times a second how do you get it onto the computer without falling behind?
also, it is for long term collection so I can't just store everything and write it once the collection is over. The edison has a built in microcontroller, but no SPI implemented yet.
Edit:
To clarify, my question is weather there is any way to get large amounts of data very fast into my embedded linux device programmatically or is there some layer between a fast SPI device and the comptuer that I don't know about. So far my mentors have suggested I 1) learn to write a device driver for the SPI device or 2) recompile an image with RT_PREEMPT.

Use of GPS chipset

I'm new to the world of GPS. Please help me understand the following:
1) Why GPS chip is required? If the GPS antenna is enough to transmit and receive data, any normal processor could do the decoding of the received GPS data.
2) Does NaviLink 6.0 has its own GPS stack? Doesn't Android has its own GPS stack?
3) NaviLink 6.0 integrates A-GPS, Bluetooth 2.1, FM Tx/Rx on a single chip. Why do you require a chip for bluetooth for FM and Bluetooth? Is FM antenna not enough? Is a separate chip required for Bluetooth too?
it's possible, and it's called "Software GPS" (there is even an open source project)
however, the CPU resources required are really big, and therefore its not really an option for hand-held mobile devices.
also, the sampling rate need to be very high, ad you need A/D converter, which also complicate things