problem when jumping from boot code to main code

RFlD · 2009-03-14 13:27:08

Hi, everyone
I am new here. I have 2 PM3(made by myself, not buying from proxmark3.com).

It took me a long time to know how to program the pm3......
But now I have some srange problem. To describe my problem clearly, let me define the four LCDs, A (yellow) B (green) C (red) D(red led away from the others), just the same as in CHAHGES.txt.

1. When I use the older version code(before 2008.12.11), I can only let the pm3 boot by clicking the "Reset&Run" button in armpgm. If I only plug in usb, it will do nothing and Windows can not recognize it. After clicking the "Reset&Run" button, the LED boot sequence is A, B, then only D (2~3 seconds later). And the pm3 will stay in such state. If I use prox.exe(prox bootrom, load, gui and so on), it will execute when B lights, and programming ".s19" file can execute smoothly, but "gui" command can not. It's just the same as eldiabl0 decribed in "http://www.proxmark.org/forum/topic/76/ … -your-fix/"(No.25), "the gui seems to see the board for a split second and then closes and tells me that it lost communications."

2.When I use the newer code (after 2008.12.11), I can program the board by holding down the button(red and yellow LEDs are lit). But after programming, it can not work either. I can only see the four leds are lit, then A B C are lit, after more than ten seconds the four are lit again, then the three..... When the four are lit, if I hold down the button, the gui can open, the windows can recognize the pm3, but it will lose connection soon.

I am try to solve the problem, and I read the bootrom code, and find something:
for the first problem:

 LED_A_ON();

    // Configure the flash that we are running out of.
    MC_FLASH_MODE = MC_FLASH_MODE_FLASH_WAIT_STATES(0) | 
        MC_FLASH_MODE_MASTER_CLK_IN_MHZ(48);

    // Careful, a lot of peripherals can't be configured until the PLL clock
    // comes up; you write to the registers but it doesn't stick.
    ConfigClocks();

    LED_B_ON();

    UsbStart();

So, we can see, after the A and B light, there's a "UsbStart()"fuction, that's why we can use the "prox XXX" command at this time.

 if((SWORD)(now - start) > 30000) {
            USB_D_PLUS_PULLUP_OFF();
            LED_A_OFF();
            LED_B_OFF();
            LED_D_ON();

            asm("mov r3, #1\n");
            asm("lsl r3, r3, #13\n");
            asm("mov r4, #1\n");
            asm("orr r3, r4\n");
            asm("bx r3\n");

We can see, just as I discribed above, the A&B off, D on! Then the boot ends, and jumping to the main code. It seems that my pm3 stays here, can not jump to the main code. But I add some LED actions at the beginning of the main code(appmain.c), the LED are lit as my design. So it seems it jumped to the main code, but after jumping, it did nothing. What can make this happen?

In the same way, I find when I use the newer codes, I encounter the same problem!

Anyone has any idea?

Thanks in advance?

(hope my poor English didn't trouble you........)

Last edited by RFlD (2009-03-14 13:29:59)

rule · 2009-03-15 15:41:34

I have no clue what can be going wrong here. Are you sure the FPGA flashing (by booting the ARM) goes well? This is done during the (isolated) red-light blinking at the end of the boot process. Or do you not even get to this stage?

There is some more information about the leds in the manual:
https://www.lafargue.name/proxmark3/running.html

Let me know if it helps, cheers,

Roel

d18c7db · 2009-03-16 12:20:18

You haven't said what flavour ARM you're using. Find out the silicon version, I remember in the past people have had weirdness with program execution that came down to the number of waitstates programed when accessing the FLASH.

IIRC it was SummoningDark who came up with the solution.

Last edited by d18c7db (2009-03-16 12:23:11)

BizonGod · 2009-03-19 21:21:49

I found somethink interesting in disasm of osimage.s19 :

osimage.elf: file format elf32-littlearm

Disassembly of section .text:
00010000 <____divsi3_from_thumb>:
10000: 4778 bx pc
10002: 46c0 nop (mov r8, r8)
10004: ea00189c b 1627c <__aeabi_idiv>
00010008 <Vector>:
10008: b500 push {lr}
1000a: f000 f927 bl 1025c <AppMain>
1000e: bc01 pop {r0}
10010: 4700 bx r0
10012: 46c0 nop (mov r8, r8)

So Vector() is located at 0x10008 insted of 0x10000.

Jump with

asm("ldr r3, = 0x10009");
asm("bx r3");

in BootROM() works.

Last edited by BizonGod (2009-03-19 21:22:03)

d18c7db · 2009-03-20 03:17:23

BisonGod that's good finding but I'm not sure what version code you're looking at as the posts in this thread are very light on specific details. I've checked the precompiled osimage.elf and .s19 in 20090301_proxmark_doob.zip and they both disassemble to the following which looks correct to me (from IDA pro). The source code also looks correct. We need to find out if this is a bug that needs fixing or is it a compile environment (or user) issue. I'm still running 20081211 myself and it's running fine.

.text:00010000 ; ===========================================================================
.text:00010000
.text:00010000 ; Segment type: Pure code
.text:00010000                 AREA .text, CODE, READWRITE
.text:00010000                 ; ORG 0x10000
.text:00010000                 CODE16
.text:00010000
.text:00010000                 EXPORT Vector
.text:00010000 Vector                                  ; DATA XREF: SimulateTagLowFrequency+28o
.text:00010000                                         ; __divsi3:loc_17354o
.text:00010000                 PUSH    {LR}
.text:00010002                 BL      AppMain
.text:00010006 ; ---------------------------------------------------------------------------
.text:00010006                 POP     {R0}
.text:00010008                 BX      R0
.text:00010008 ; ---------------------------------------------------------------------------
.text:0001000A                 ALIGN 4
.text:0001000C
.text:0001000C loc_1000C                               ; CODE XREF: CodeIso14443bAsReader+Ap
.text:0001000C                                         ; SimulateIso14443Tag+1Ep ...
.text:0001000C                 LDR     R2, =ToSendMax
.text:0001000E                 MOVS    R3, #1
.text:00010010                 NEGS    R3, R3
.text:00010012                 STR     R3, [R2]
.text:00010014                 LDR     R2, =unk_200000
.text:00010016                 MOVS    R3, #8
.text:00010018                 STR     R3, [R2]
.text:0001001A                 BX      LR

RFlD · 2009-03-20 15:04:57

Thanks, BizonGod.

I modified the code as you suggested, but it doesn't work, either.(but it‘s different from the code which isn't modified)
I'll try to locate the problem.
if I had any progress, I would post it here!
,

BizonGod · 2009-03-20 17:04:23

I have my modified firmware for my specific hardware. I have compiled it with GNUARM (gcc 4.3.2).
So jump to main code works (but with addinational offset caused by this stub (i can't move it now).
But again USB don't work. Previously it was caused by my big mistake in ld script in bootrom.
I will try to track this in mainapp.

BizonGod · 2009-03-22 23:15:18

After few hours of debugging i noticed that most of errors are data-abort exceptions.
Errors occurs independly of code (it was ok in asm). So i started thinking about dirty
reads from flash. I started reading about flash controller, and i found in datasheet:

page 115
FMCN: Flash Microsecond Cycle Number
Before writing Non Volatile Memory bits (Lock bits, General Purpose NVM bit and Security bits), this field must be set to the
number of Master Clock cycles in one microsecond.
When writing the rest of the Flash, this field defines the number of Master Clock cycles in 1.5 microseconds. This number
must be rounded up.

So it looks, that FMCN should be set 72, instead 48. (48 MHz MCLK * 1.5us = 72)

page 576
FWS - Read Operations - Maximum Operating Frequency (MHz)
0 - 1 cycle - 30
1 - 2 cycles - 55
2 - 3 cycles - 55
3 - 4 cycles - 55

So it also looks it should be set 1 instead of 0.

In BootROM() should looks like

// if 512K FLASH part - TODO make some defines
if ((DBGU_CIDR | 0xf00) == 0xa00) {
MC_FLASH_MODE0 = MC_FLASH_MODE_FLASH_WAIT_STATES(1) |
MC_FLASH_MODE_MASTER_CLK_IN_MHZ(0x48);
MC_FLASH_MODE1 = MC_FLASH_MODE_FLASH_WAIT_STATES(1) |
MC_FLASH_MODE_MASTER_CLK_IN_MHZ(0x48);
} else {
MC_FLASH_MODE0 = MC_FLASH_MODE_FLASH_WAIT_STATES(1) | // 1 instead of 0
MC_FLASH_MODE_MASTER_CLK_IN_MHZ(72); // 72 instead of 48
}

Can anyone confirm?

RFlD · 2009-03-23 13:09:58

Hi, BizonGod
I'll modify as you mentioned.
But did it work on your board?

BizonGod · 2009-03-23 15:20:53

Yes

d18c7db · 2009-03-23 21:42:52

BizonGod as I said in the third post in this thread, I had a feeling it might have been something like that and SummoningDark had come across the same issue with his ARM (512K version). It's possible that different ARM chip variants have different access speeds on the FLASH which is why some, like mine for example, work OK with the faster settings while others like RFID's and yours crash.

It will probably pay to err on the side of caution and set the timing values for the slowest case.

Last edited by d18c7db (2009-03-23 21:45:38)

RFlD · 2009-03-24 16:10:58

BizonGod
Thanks, the way which you mentioned to modify the code helps me, but I have new problem now.
It seems that the fpga in my board doesn't work!
Could anyone give me a way to locate the problem in fpga?

reuse · 2009-04-24 12:41:39

hello, BizonGod,
i confirm that your solution is right.
my ARM is AT91SAM7S256 ,witch buy form JR(proxmar3.com).
exept the firmware come with the board , all other firmware act as what RFID described.

so somebody can check if the code should be amend in the svn dir.
thx!

edo512 · 2009-04-25 08:24:37

reuse wrote:

so somebody can check if the code should be amend in the svn dir.
thx!

-> BizonGod / others : just contact me to be added as contributors to SVN.

As a sidenote, my PM3 bought from proxmark3.com works fine on all current versions...

Last edited by edo512 (2009-04-25 08:24:49)

reuse · 2009-04-25 10:14:57

edo512 wrote:

reuse wrote:
so somebody can check if the code should be amend in the svn dir.
thx!
-> BizonGod / others : just contact me to be added as contributors to SVN.
As a sidenote, my PM3 bought from proxmark3.com works fine on all current versions...

hi,edo512, today i tried all the version again. all works. so strange!! but yestday it not work if not change.

wait more people's feedback.

Proxmark3 community

Announcement

#1 2009-03-14 13:27:08

problem when jumping from boot code to main code

#2 2009-03-15 15:41:34

Re: problem when jumping from boot code to main code

#3 2009-03-16 12:20:18

Re: problem when jumping from boot code to main code

#4 2009-03-19 21:21:49

Re: problem when jumping from boot code to main code

#5 2009-03-20 03:17:23

Re: problem when jumping from boot code to main code

#6 2009-03-20 15:04:57

Re: problem when jumping from boot code to main code

#7 2009-03-20 17:04:23

Re: problem when jumping from boot code to main code

#8 2009-03-22 23:15:18

Re: problem when jumping from boot code to main code

#9 2009-03-23 13:09:58

Re: problem when jumping from boot code to main code

#10 2009-03-23 15:20:53

Re: problem when jumping from boot code to main code

#11 2009-03-23 21:42:52

Re: problem when jumping from boot code to main code

#12 2009-03-24 16:10:58

Re: problem when jumping from boot code to main code

#13 2009-04-24 12:41:39

Re: problem when jumping from boot code to main code

#14 2009-04-25 08:24:37

Re: problem when jumping from boot code to main code

#15 2009-04-25 10:14:57

Re: problem when jumping from boot code to main code

Quick reply

Board footer