Proxmark3 community

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

ARM code seems way flakey

I wonder if it's just me experiencing this or is it a common problem. I've flashed several versions of osimage.s19 to the board, including the original from 20080514_prox.zip and the 2008.09.17-armpgm-ebuller-proxmark3-image.S19 and some I've compiled myself and all suffer from the same sort of buffer problem, specifically with the command "loread".

When that command is issued, internal variables are overwritten by the buffer and the board resets after a few seconds (presumably crashes and WDT resets it)

Looking at the function AcquireRawAdcSamples125k() in appmain.c I've determined that the global buffer BigBuf lives at base address 0x002000f8 and has a size of 10240 words (10240*4 = 40960 bytes) so BigBuf occupies RAM space 0x002000f8 - 0x0020A0f8 but the variables used in that function have base addresses within the buffer space, for example , "n " is at 0x00203ea0 and "i" is at 0x00203eac so as the buffer is filled with samples "n" and "i" and even the buffer pointer "dest" is overwritten with sample data so the loop starts writing sample data outside the buffer all over the RAM memory space, etc.

WTF!

Any idea why the memory allocation of the variables is so screwed? Is this a compiler issue? Has anyone found an easy fix?

Last edited by d18c7db (2008-11-18 03:31:55)

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: ARM code seems way flakey

Well after some further debugging, I have a possible fix, move the stack pointer to the top of RAM (gives the program more room to put it's variables in). This is for the top of RAM for a 256Kb ARM, lower RAM models needs adjusting accordingly. This has stopped the crashing and it's now returning data from the buffer as it should.

Change start.c as follows:

void Vector(void)
{
    asm("ldr    r3, = 0x0023fff8\n");
    asm("mov    sp, r3\n");
    AppMain();
}

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: ARM code seems way flakey

Oh I just realised that in a blonde moment I confused the FLASH size (256K) with the RAM size (64K) so the stack pointer should really be set to 0x20fff8, however due to the effect of address wrapping this doesn't really matter.

In any case this code belongs in the bootrom which is where SP is initialised so the real fix is to change flash-reset.s and ram-reset.s SP initialisation to "ldr sp, = 0x0020fff8" which will work on 64k through to 4k devices since due to address wrapping 0x0020fff8 is equivalent to 0x00207ff8 on a 32k device, 0x00203ff8 on a 16k device, etc. I've tested this on my proxmark's bootrom code and it works.

Alternatively one can read the DBGU_CIDR register which has the FLASH and RAM size of the ARM processor and set SP accordingly but that would require much more code compared with the one line assignment above.

rule

Member

Registered: 2008-05-21

Posts: 417

Re: ARM code seems way flakey

Hey,

So does this mean the 512k chip can also be used now? Did you got a new flash working?
Maybe we can build a new binary with a new bootloader which works on all chip versions?

Thanks in advance,

  Roel