Flashing Issues

ntk · 2015-07-11 23:27:09

Lutcheti, that is old post before you have sent your report.

Jump is in now, he runs linux. that is good news. He will send you the flasher and the elf-files, so you can try to see any different.

Remember to replace the power cable. An other USB mini-usb should help ATM.

Also one question you had not answered. when you run
dmesg | grep 'usb' can you see the proxmark all the time? yester day you said you see it while and after flasing what seems to be odd.

pls make sure of that to be sure the connection is there all time.

Let me hear the good news

ntk · 2015-07-11 23:34:54

and Jump

I have interest in seeing the report of flash the two files on linux side. If you could send here....the difference is 100blocks larger to write! How possible? Mine I have sent few posts back.

[== Undefined ==]
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b10->0x00000b10) [RWX] @0x298

Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00023a40->0x00023a40) [R X] @0x94
1: V 0x00200000 P 0x00125a40 (0x000019fc->0x000019fc) [RW ] @0x23ad4
Note: Extending previous segment from 0x23a40 to 0x2543c bytes

Waiting for Proxmark to appear on //./com4. Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on //./com4. Found.

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100d0f [0xb10 / 6 blocks]...... OK

Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x0012743b [0x2543c / 299 blocks]..................................
................................................................................
................................................................................
................................................................................
......................... OK

Resetting hardware...
All done.

Last edited by ntk (2015-07-11 23:35:29)

jump · 2015-07-11 23:36:56

In that case I would effectively bet on an issue with the Proxmark.
Again I think that in worst case, the ARM processor is failing and this component is around 16 euros. Nothing compared to the 300$ of a full unit

ntk · 2015-07-12 01:11:56

yes 16 euros but the labour .... if you don't know how to do.... that could be easily 80 more euros on top.

If you bet on the PM3, I like to know what cause that issue ... When PM3 arrived I look at the Hirose connector, it feels flimsy I feel like we have a bomb of bad news on our hand.... But now also with the ARM processor ...or flsh memory ... perhaphaps FPGA Oh gosh very very bad news ...

So Did Lutcheti use your elf files and flasher without success?

Lutcheti, please don't forget to capture the flash report and put here ... Is the size and blocks and write address different then flashing with your elf files?

Appropos Do you ever have issue with the PM3 connectors? Do you know when Hirose connector broken how long and what cost for repair?

EDIT
Have you taken any prevention against an early leaving of Hirose Connector? Could you take any?

Last edited by ntk (2015-07-12 01:18:38)

jump · 2015-07-13 14:18:37

lutcheti, I am very puzzled by this mysterious error of block 16.
I've gone through both the datasheet of the ARM processor and the code of the flasher and that just makes no sense... The block 16 has nothing special beside being right after the first 16KB of flash. But the flash in the AT91SAM7 is just 1 plane of 256-byte pages. And it's odd that this specific block (#64) is failing for at least 2 persons unless the ARM processors are part of a same defective lot.

I would like to try to narrow down this issue but as this could be pretty noisy considering we are not in the same country, I suggest we do that by mail or chat and put the results, if any, on this forum to help others who are facing the same situation.
Again, in worst case, that means replacing the ARM processor and considering that the 256KB ARM is not produced anymore, you'll get an upgrade to the 512KB in the process But maybe we can find something.

meter · 2015-07-13 16:07:23

I think the problem is the compiler. 390 blocks are too much. So I think also the bootloader is not running correctly.
For example I use arm-none-eabi gcc from launchpad https://launchpad.net/gcc-arm-embedded/+download, version 4.7 make some problem to bootloader.
When I flash sometimes it stuck because not receive the ACK from microcontroller, with gcc 4.8 this problem disappear.

jump · 2015-07-13 16:21:05

lutcheti already tried files provided by asper for Windows.

But in any case, that's easy to rule out: http://demo.ovh.eu/en/ad72bd39fd30661cea2d50d8e1db1b36/
Here are the bootrom and the fullimage that I compiled for the last github revision (master:a83d091885dc) and I successfully flashed my proxmark3 with them.

lutcheti, could you try those files with the following command (after uncompressing my files of course and adapting the command to point to them):

client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf

Unfortunately, I cannot provide the flasher as all my computer are running 64bit OS and I may miss 32bit libs to compile it for 32bit linux statically.

lutcheti · 2015-07-20 14:30:43

jump wrote:

lutcheti, I am very puzzled by this mysterious error of block 16.
I've gone through both the datasheet of the ARM processor and the code of the flasher and that just makes no sense... The block 16 has nothing special beside being right after the first 16KB of flash. But the flash in the AT91SAM7 is just 1 plane of 256-byte pages. And it's odd that this specific block (#64) is failing for at least 2 persons unless the ARM processors are part of a same defective lot.
I would like to try to narrow down this issue but as this could be pretty noisy considering we are not in the same country, I suggest we do that by mail or chat and put the results, if any, on this forum to help others who are facing the same situation.
Again, in worst case, that means replacing the ARM processor and considering that the 256KB ARM is not produced anymore, you'll get an upgrade to the 512KB in the process But maybe we can find something.

Sorry for the delay, I was abroad and came back home yesterday.
I'm ready to follow your instructions: I'll PM you my email.

lutcheti · 2015-07-20 14:38:43

jump wrote:

lutcheti already tried files provided by asper for Windows.
But in any case, that's easy to rule out: http://demo.ovh.eu/en/ad72bd39fd30661cea2d50d8e1db1b36/
Here are the bootrom and the fullimage that I compiled for the last github revision (master:a83d091885dc) and I successfully flashed my proxmark3 with them.
lutcheti, could you try those files with the following command (after uncompressing my files of course and adapting the command to point to them):
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
Unfortunately, I cannot provide the flasher as all my computer are running 64bit OS and I may miss 32bit libs to compile it for 32bit linux statically.

Ok I tried this and obtained:

➜  lucca@lucca-XPS : Proxmark/FRESH/proxELF  client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b60->0x00000b60) [RWX] @0x298

Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00024318->0x00024318) [R X] @0x94
1: V 0x00200000 P 0x00126318 (0x000019a4->0x000019a4) [RW ] @0x243ac
Note: Extending previous segment from 0x24318 to 0x25cbc bytes

Waiting for Proxmark to appear on /dev/ttyACM0.......... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0. Found.

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100d5f [0xb60 / 6 blocks]...... OK

Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x00127cbb [0x25cbc / 303 blocks]................Error: Unexpected reply 0x00fe (expected AC
 ERROR
Error writing block 16 of 303

iceman · 2015-07-20 14:56:41

How about you do your flash cmd in two steps? (just a stupid guess)

//just obvious, but:
is this is the latest *.elf files compiled from github source? And the flasher is also compiled from GitHub source?

client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf 
client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf

lutcheti · 2015-07-20 15:27:30

iceman wrote:

How about you do your flash cmd in two steps? (just a stupid guess)
//just obvious, but:
is this is the latest *.elf files compiled from github source? And the flasher is also compiled from GitHub source?
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf 
client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf

Ok my master and yours did not matched.
So I restart:

git checkout a83d091885dc
make clean
make all
rm -rf bootrom armsrc
cp ../bootrom .
cp ../armsrc .
client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf 
client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf

where ../ contains the bootrom/armsrc compiled by jump.
Now, the PM3 gets stuck 'waiting for PM3 to appear....'. I guess, I need to reboot and try again. I will edit this post soon.
[EDIT]
Ok I got this:

➜  lucca@lucca-XPS : Proxmark/FRESHGIT/pm3_elf git:(a83d091) ✗ client/flasher /dev/ttyACM0 -b bootrom/obj
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b60->0x00000b60) [RWX] @0x298

Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00024318->0x00024318) [R X] @0x94
1: V 0x00200000 P 0x00126318 (0x000019a4->0x000019a4) [RW ] @0x243ac
Note: Extending previous segment from 0x24318 to 0x25cbc bytes

Waiting for Proxmark to appear on /dev/ttyACM0......... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0...... Found.

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100d5f [0xb60 / 6 blocks]...... OK

Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x00127cbb [0x25cbc / 303 blocks]................Error: Unexpected reply 0x00fe (expected AC
 ERROR
Error writing block 16 of 303

Last edited by lutcheti (2015-07-20 15:32:46)

iceman · 2015-07-20 15:37:50

my fork is 348blocks (or was the last time I checked)
but don't use my fork, use PM3 master to start with.

But if you can compile the checkouted code, you should use those *.elf files.

If you are in europe, as a last resort you can always send it to me and I'll see if I can get yr pm3 to work with using a segger.

piwi · 2015-07-20 19:37:34

What about lock bits being set? Block 16 is the beginning of the second lockable area of the ARMs flash memory.

marshmellow · 2015-07-20 19:44:27

very interesting thought piwi.
some others that had lock bit troubles:
http://www.proxmark.org/forum/viewtopic.php?id=1758
http://www.proxmark.org/forum/viewtopic.php?id=1509

piwi · 2015-07-20 21:59:37

I have added a branch "lock_bits" to my repository (https://github.com/pwpiwi/proxmark3.git). This implements small changes in bootloader and flasher in order to print more information than just "Unexpected Reply 0x00fe" when aborting (including e.g. the lock bits).

Please try. If this confirms my suspicion, then the next step would be to add a lock bit clearing function...

lutcheti · 2015-07-22 10:27:35

piwi wrote:

I have added a branch "lock_bits" to my repository (https://github.com/pwpiwi/proxmark3.git). This implements small changes in bootloader and flasher in order to print more information than just "Unexpected Reply 0x00fe" when aborting (including e.g. the lock bits).
Please try. If this confirms my suspicion, then the next step would be to add a lock bit clearing function...

Thanks.
I did:

git clone https://github.com/pwpiwi/proxmark3.git
git checkout lock_bits
make all
cd client; make; cd..

and obtained:

➜  lucca@lucca-XPS : Proxmark/TestLock/proxmark3 git:(lock_bits) ✗ client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf armsrc/obj/fullimage.elf
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x00000b60->0x00000b60) [RWX] @0x298

Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00024318->0x00024318) [R X] @0x94
1: V 0x00200000 P 0x00126318 (0x000019a4->0x000019a4) [RW ] @0x243ac
Note: Extending previous segment from 0x24318 to 0x25cbc bytes

Waiting for Proxmark to appear on /dev/ttyACM0...... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0. Found.

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100d5f [0xb60 / 6 blocks]...... OK

Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x00127cbb [0x25cbc / 303 blocks]................Error: Unexpected reply 0x00fe (expected ACK)
 ERROR
Error writing block 16 of 303

piwi · 2015-07-22 12:10:30

You need to flash the fullimage.elf once again in order to use the new bootloader when flashing.

lutcheti · 2015-07-22 12:14:17

piwi wrote:

You need to flash the fullimage.elf once again in order to use the new bootloader when flashing.

Like this ?

  lucca@lucca-XPS : Proxmark/TestLock/proxmark3 git:(lock_bits) ✗ client/flasher /dev/ttyACM0  armsrc/obj/fullimage.elf                                                                                                                                                                                         (lock_bits⚡)
Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x00024318->0x00024318) [R X] @0x94
1: V 0x00200000 P 0x00126318 (0x000019a4->0x000019a4) [RW ] @0x243ac
Note: Extending previous segment from 0x24318 to 0x25cbc bytes

Waiting for Proxmark to appear on /dev/ttyACM0..... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0...... Found.

Flashing...
Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x00127cbb [0x25cbc / 303 blocks]................Error: Unexpected reply 0x00fe (expected ACK)
 ERROR
Error writing block 16 of 303

piwi · 2015-07-22 13:10:49

Did you rebuild the flasher? make clean before make?

lutcheti · 2015-07-22 14:16:21

piwi wrote:

Did you rebuild the flasher? make clean before make?

It was a fresh clone so I guess that was not needed. But I tried again with a make clean in ./client and in ./ to make sure and got the same error

piwi · 2015-07-23 07:53:59

Let's start over from scratch. Nobody seems to have asked some basic questions yet:

You had a working Proxmark and Client before starting to flash?
Which software release was this?
Could you ever successfully flash before?
You still can flash (well, up to the block 16 error) WITHOUT pressing the PM button during power up?
If you revert your client to the previous (working) version before you tried to flash: does it still work?
What's the version of your ARM SoC? Have a look at the second biggest square chip on the PM3 board. There should be printed "AT91SAM7Sxxx". The xxx is your flash memory size in KBytes. In addition there will be a 4 digit manufacturing date (2 digits year, 2 digits week). Then either right of the manufacturing date there is a single capital letter which is the Chip Revision, or left to the manufacturing date is a 6 digit manufacturing number. You don't happen to have a AT91SAM7S512 Revision B ?

lutcheti · 2015-07-23 11:49:41

piwi wrote:

Let's start over from scratch. Nobody seems to have asked some basic questions yet:
You had a working Proxmark and Client before starting to flash?
Which software release was this?
Could you ever successfully flash before?
You still can flash (well, up to the block 16 error) WITHOUT pressing the PM button during power up?
If you revert your client to the previous (working) version before you tried to flash: does it still work?
What's the version of your ARM SoC? Have a look at the second biggest square chip on the PM3 board. There should be printed "AT91SAM7Sxxx". The xxx is your flash memory size in KBytes. In addition there will be a 4 digit manufacturing date (2 digits year, 2 digits week). Then either right of the manufacturing date there is a single capital letter which is the Chip Revision, or left to the manufacturing date is a 6 digit manufacturing number. You don't happen to have a AT91SAM7S512 Revision B ?

Ok I answer to all questions:

Yes I had.
It was the release v2.0.0. Everything was working well. I needed to flash to get new implem of 14b commands.
Yes I had because I think my PM3 had never been flashed before. I had to use an old repository to get a working flasher. I did:
```
svn checkout -r 623 http://proxmark3.googlecode.com/svn/trunk proxmark3-old
```
and the usual stuff.
Yes, I never push the button and the flasher seems to disconnect and reconnect the PM3 on its own. The whole process (flash bootrom and then fullimage) takes about 5 sec. When I push the button while flashing I get the same error .

Yes it works with the v2.0.0 client and here is 'hw version':

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: /-suspect 2015-05-19 19:47:20                 
#db# os: /-suspect 2015-05-19 19:47:20                 
#db# HF FPGA image built on 2015/03/09 at 08:41:42                 
uC: AT91SAM7S256 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 256K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory

And 'hw tune':

proxmark3> hw tune

Measuring antenna characteristics, please wait.........          
# LF antenna:  0,00 V @   125.00 kHz          
# LF antenna:  0,00 V @   134.00 kHz          
# LF optimal:  0,00 V @ 12000,00 kHz          
# HF antenna: 12,80 V @    13.56 MHz          
# Your LF antenna is unusable.

Version of ARM SoC: AT91SAM7S256,
two letters below: AU,
4 digits below on the left: 1121,
something below I can hardly read: 1P0226 (I will double check this one tonight, I need to be at home to open the protection box).

Last edited by lutcheti (2015-07-23 14:05:30)

piwi · 2015-07-23 13:58:01

No need to open the protection box - the hw version command gives us the ARM version (AT91SAM7S256 Rev. B). This is a "good" version and has no known errors with the flash.

Did you have an antenna connected during hw tune?

All in all it looks like you cannot flash anymore although the PM3 pretends to do so (you are still on a version from May 19th although you tried several times to flash). Might be broken HW or corrupt bootloader. As a last chance try flashing via the JTAG port.

lutcheti · 2015-07-23 14:08:36

piwi wrote:

No need to open the protection box - the hw version command gives us the ARM version (AT91SAM7S256 Rev. B). This is a "good" version and has no known errors with the flash.
Did you have an antenna connected during hw tune?
All in all it looks like you cannot flash anymore although the PM3 pretends to do so (you are still on a version from May 19th although you tried several times to flash). Might be broken HW or corrupt bootloader. As a last chance try flashing via the JTAG port.

I edited my post with the antenna plugged in.
I do not have a Bus Pirate. If that's sure it is the only remaining way to get the PM3 working, I guess I have to buy one

Proxmark3 community

Announcement

#51 2015-07-11 23:27:09

Re: Flashing Issues

#52 2015-07-11 23:34:54

Re: Flashing Issues

#53 2015-07-11 23:36:56

Re: Flashing Issues

#54 2015-07-12 01:11:56

Re: Flashing Issues

#55 2015-07-13 14:18:37

Re: Flashing Issues

#56 2015-07-13 16:07:23

Re: Flashing Issues

#57 2015-07-13 16:21:05

Re: Flashing Issues

#58 2015-07-20 14:30:43

Re: Flashing Issues

#59 2015-07-20 14:38:43

Re: Flashing Issues

#60 2015-07-20 14:56:41

Re: Flashing Issues

#61 2015-07-20 15:27:30

Re: Flashing Issues

#62 2015-07-20 15:37:50

Re: Flashing Issues

#63 2015-07-20 19:37:34

Re: Flashing Issues

#64 2015-07-20 19:44:27

Re: Flashing Issues

#65 2015-07-20 21:59:37

Re: Flashing Issues

#66 2015-07-22 10:27:35

Re: Flashing Issues

#67 2015-07-22 12:10:30

Re: Flashing Issues

#68 2015-07-22 12:14:17

Re: Flashing Issues

#69 2015-07-22 13:10:49

Re: Flashing Issues

#70 2015-07-22 14:16:21

Re: Flashing Issues

#71 2015-07-23 07:53:59

Re: Flashing Issues

#72 2015-07-23 11:49:41

Re: Flashing Issues

#73 2015-07-23 13:58:01

Re: Flashing Issues

#74 2015-07-23 14:08:36

Re: Flashing Issues

Board footer