cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F429I-DISCO Board - Accessing Embedded SRAM & Data Transfer to PC

sakibi15
Associate II
Posted on August 10, 2015 at 23:56

Hello,

Here is a problem I'm currently working on:

Board: STM32F49I-DISCOVERY

Microcontroller: STM32F429ZIT6U

Goal: Access embedded SRAM (112 KB, 16 KB, 64 KB) and transfer content of memory to PC. For e.g. I am sending bytes to a PC which will eventually be a sequence of 0's and 1's that correspond to a specific memory location for the microcontroller.

I've set up a template project using the STM32CubeF4 package for the IAR EWARM toolchain and it has an empty main entrypoint. I created a function readEmbeddedSRAM which has a pointer to memory address 0x20020000 which is the beginning of the memory block of 64 KB in the memory map of ARM Cortex M4 based microcontrollers (which is the core of the ST microcontroller I'm using). Now, I am reading this byte accordingly but how do I send this information to the PC? Would I be able to console output this data or send it via USB using VCOM port interface? I need the memory contents of the 64 KB SRAM in between 0x20020000 and 0x2002FFFF.  I essentially need a mechanism to acquire this data. A screenshot is shown below/attached.

0690X00000605aXQAQ.png

Ideas: 

- I was thinking of setting up USB CDC to transfer data to my laptop/PC via the USER USB connector using the USB-OTG peripheral. How can I replicate the project CDC_Standalone in the STM32F4x29I-EVAL -> Applications -> USB_Device directory to be compatible with my STM32F429I-DISCOVERY board that I have. It appears that data/bytes are transferred via a VCOM port to the PC.

- How can I print the contents of the memory to the console output or somehow else view this information? Once I have the data - I can analyze it accordingly to my liking and perform statistics.

Any help/feedback/pointers are sincerely appreciated!

- Sakib I.
4 REPLIES 4
Posted on August 11, 2015 at 04:07

Analyze it to what end?

You could dump out the hex bytes in an ASCII form, that would be readable on a serial terminal/console.

For 64KB I might be more inclined to use an XMODEM-1K protocol so I could get an intact image quickly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
sakibi15
Associate II
Posted on August 11, 2015 at 20:53

Thanks for the response Clive!

Let me clarify - I'm actually interested in the fresh start-up values of the embedded SRAM. Ideal SRAM bitcells (containing either a 0 or 1) will latch to either value with 50% probability upon power-up. However, due to process variation and an inherent mismatch in the bitcell topology (asymmetry in memory cell composed of CMOS either 6T or 8T for e.g.) this is not always the case and the bitcell may tend to latch to a 0 or 1 more often than the other, for e.g. 65% a 1 and 35% a 0. I'm interested in taking a look at the start-up values many times.

I'm also performing this experiment on another board by Atmel - where they have a USB CDC example and have configured the UART to be able to transmit data serially and thus my terminal application on Windows (HyperTerminal) is able to view this data via the VCOM port. I am simply printing the address of the memory and then taking a look at the content of the data. However, the data has been pre-initialized to values of 0 when I run the main application code. I may need to look into the bootloader or start-up sequence of the embedded SRAM and make sure it's not modified or pre-initialized. It takes about 3 minutes to see 32 KB of printed data on the terminal console.

Would you be able to elaborate on the XMODEM-1K protocol? How would I approach this for the STM32F429I-DISCO board with the STM32F429ZIT6U MCU?

Thanks in advance.

- Sakib I.

Posted on August 11, 2015 at 22:13

Well the C runtime start up code often zeros statics. If you remove the memory from the linker's purview it shouldn't mess with it. The Keil code calls __main, IAR I think it's __cstartup or something.

Google is your friend

https://en.wikipedia.org/wiki/XMODEM

There's got to be plenty of salient material out there if you look. It's a pretty simple protocol and would work well for transferring a large block of memory to a PC side application waiting to take delivery of such.

The SRAM content shouldn't change across a reset (soft or hard), you'd have to remove the supply and discharge things effectively for it to be remotely random (cold).

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
sakibi15
Associate II
Posted on August 17, 2015 at 23:32

@clive1

I could not identify the C runtime start-up/initialization code/sequence for the STM32F429ZIT6U MCU.

I've accomplished the embedded SRAM accesses for another board & MCU - by Atmel. The SRAM is accessed and each data capture of the full 32 KB (for that particular MCU) is saved as a binary file. It's essentially a memory dump of hex bytes saved in a .bin file. The data captures are super fast - less than a second. I'm staying away from terminal applications since printing to the console is a slow task.

I'm using an open source tool which leverages the onboard embedded debugger (EDBG) to access the internal memories via SWD port and communicate this back to the host device (PC) via USB. The tool is written by adhering to the CMSIS-DAP interface firmware. The tool is

https://github.com/ataradov/edbg

Now, ST-LINK is the equivalent of EDBG, is an onboard debugger and what not however the way it communicates acquired information from the MCU back to PC is specific to ST and not based off of CMSIS-DAP - from my understanding. Apologies if I'm using incorrect terminology or misinterpreting this.

Is there a tool out there that can be built on a Windows environment that is simply command line based. I'm staying away from integrated development environments since accessing fresh uninitialized start-up values of SRAM is a low level task. The closest tool I've come across is

https://github.com/texane/stlink

. Any thoughts and ideas?

Thanks in advance

- Sakib I.