Read out Start-Up RAM values

[an]

Posted on October 12, 2012 at 11:28

Hey there,

I am pretty new to micrcontrollers and such. I recently bought a STM32VL Discovery, which I am programming with CoCoox IDE. My goal is to read out the start-up values of internal RAM. By start-up values I mean the values of RAM cells just after the power-up of the device when no other application interferred with the ram. Is this possible somehow? Could you guys guide me to some literature or give me some hints? Thanks in advance! #describe-the-goal-not-the-step

[Tesla DeLorean]

Posted on November 16, 2012 at 15:31

Sorry, 8 MHz for the F1 series, way off in F2 and F4 land these days.

ldr r0, =0x40021000 ; RCC
ldr r1, =0x00004004 ; USART1EN | IOPAEN (GPIOA)
str r1, [r0, #0x18] ; RCC_APB2ENR
ldr r0, =0x40010800 ; GPIOA
ldr r1, =0x444444B4 ; PA.9 USART1_TX 50MHz AF_PP
str r1, [r0, #4] ; GPIOx_CRH
ldr r0, =0x40013800 ; UART1
movs r1, #0
strh r1, [r0, #4] ; +4 USART_DR
movs r1, #69 ; 8MHz / 69 == 115200
strh r1, [r0, #8] ; +8 USART_BR
movs r1, #0x0600
strh r1, [r0, #16] ; +16 USART_CR2 = 0x600
movs r1, #0
strh r1, [r0, #16] ; +16 USART_CR2 = 0
movs r1, #0
strh r1, [r0, #24] ; +24 USART_GTPR = 0 - Prescaler
movw r1, #0x200C ; 8-bit, no parity, enable TX,TX
strh r1, [r0, #12] ; +12 USART_CR1
ldr r2, =0x2000 ; Size = Length (8K)
ldr r3, =0x20000000 ; Mem = RAM Address
iu1 ldrh r1, [r0, #0] ; USART->SR
ands r1, #0x80 ; TXE
beq iu1
ldrb r1, [r3], #1 ; [Mem++]
strh r1, [r0, #4] ; USART->DR
subs r2, r2, #1 ; Size--
bne iu1

[M0NKA]

Posted on November 17, 2012 at 10:05

Lovely! Tnx for sharing

[an]

Posted on November 19, 2012 at 10:05

Thanks so much! I will try this as soon as possible.

Kind Regards

[an]

Posted on November 26, 2012 at 15:20

Hi cl1ve,

I was trying to use your code. I inserted it right after Reset_Handler: First, Eclipse was complaining about iu1. Obviously there is a '':'' missing to indicate a label. Afterwards the code compiled. I am using Hyperterminal to receive values from USART. However, I only get one byte != '''' and the rest are just empty spaces. Also, I only receive stuff if I debug. If I run the program ''normaly'', nothing is printed in hyperterminal. Cheers.

[Tesla DeLorean]

Posted on November 26, 2012 at 15:57

I'm using Keil/ARM assembler syntax, GNU might need other things.

It should transmit raw binary values, not ASCII. Suggest you use a better terminal app like RealTerm which can display Hex values for binary data.

[an]

Posted on November 27, 2012 at 17:34

Hi clive1,

I installed KEIL/ARM and your ASM code is worling like charm - kudos! One more question: It look like the ASM code (which I put right at the beginning of the Reset_Handler marker) gets executed if I am in debugging mode. However, if I run code ''normally'' it seems not to transmit anything. I tried to put a loop into the asm code by adding a marker (''foo'') before the first line of your code and adding a ''b foo'' at the end of your code. Again this works well in debugging mode and it infinitely loops through your asm code, transmitting the binary values. However, it does nothing in ''normal'' mode. Cheers

[an]

Posted on January 31, 2013 at 09:44

Sorry for bumping this rather old thread.

@clive1: Can you tell me how did you created the ASM code? Is there a reference with respect to the register values for UART settings or did you code it in C and used the assembly after compilation process?I would like to do this with a ARM MCU of another brand and do not really know how to proceed.Thanks!

[Tesla DeLorean]

Posted on January 31, 2013 at 10:52

My primary data sources of information were the reference manual for the part and the C source code for the library. ie Memory maps, register addresses and bit definitions.

I've been writing code in assembler for decades, so don't really need to look at compiler output much, but it can be helpful, as can looking at other assembler listings or examples. I come from a generation which learned how to program in assembler before we learned PASCAL and C, and hand assembled machine code, so my perspective is a bit skewed. The trick is to understand the memory addresses in the target, and what processor registers you're using to hold specific values, or are available for other uses. I used hex constants here because a) it was more efficient to do so, and b) didn't require a large number of equates or includes. You'll need to look at the flow for setting up the clocks, GPIOs and USART on your new target device.