Reading out FW of an 8051 via SPI

Hi everyone,

I'm trying to read out the firmware of a ZBS242 which is a microcontoller based on a 8051 structure. The controller is the brain of an older electronic shelf labeling unit and controls radio and display functions.

Actually the system has already been analyzed and documented, but as I do have another hardware revision with another screen controller, the intention was to compare the hex-files and search for differences.

There is a very good documentation on how everything works by Dmitry and even an SDK, but due to not having enough experience in
mc architecture and programming I am not sure what I am doing wrong.

The controller does have 64k flash, but if I try to read out everything with my code (read_flash()),
I get ony values from 0x00 to 0x8C - then everything stops.

So I actually don't know if the problem is caused by my code or the lack of understanding of the 8051 structure.

The connection gets established and I can read and write SFRs and so on (at least the serial output says so), but by using the method of reading out 1 to 65535 with sending low and high bytes I only get to 8C

So then in second attempt I tried to use another way (read_flash_new()), using the on-the-air upgrade functions
in the code documentation, where the code gets read out and gets buffered in the "xdata" of the MC.
I tried to keep to the documentation here, but I had some serious problems to convert the C code for the MC
in the SDK to arduino.

Might someone be able to have a look and maybe an idea what I am doing wrong?

Here is my code.

Please excuse the spagetthi coding

Hi DL5SMB

do you find consistent 8051 instructions in the 0000-008C part that you manage to read ? you must have an interrupt vector at address 0003, on 3 bytes, a jump instruction (jmp (address) )? if yes, it's a good thing, the read command is ok, the problem may be elsewhere ?

On an old 8051 project, I find at address 0x0000 (reset vector): 02 xx xx, which corresponds to: JZ (addr16) (Jump if 0 addr 16)
I expected to find LJMP (adr16) (Long Jump), another mystery for me!

Then, in 0x0003, it's the interrupt vector (I don't remember which one), we must find another LJMP adrr16 (or SJMP, "shortjmp")

Hi PatMax,

Thanks for your answer. I had not enough time for having a look into this, I will try after work today and post some examples.

Sascha

Still at work but I might have found out what's wrong.
I am sending out the low byte and the high byte, but I don't read back two values (2 bytes), only one. So this might be the mistake.

So, this is what my codes reads back and gives out via the serial interface.

I noticed I wrote nonesense this afternoon.

The documentation states clearly that it shall be a four byte command. The first byte to read flash, the second and third byte (high and low byte) determiine the adress and the fourth byte is the read value: So no high and low byte for the value. I tried it nevertheless but I received nearly only "FF" and "00". Does not seem right.

But 0x0000 is a "2", as well as 0x0003.

I've got some new discoveries.

I noticed that if I try to read out the special function registers, the program stops also after
receiving the value of "0x8c". Not so sure if this is a coincidence. So I adapted the program to begin from different starting registers. If i start from 8C, 8D, 8E or 8F it always gives back only one value and then stops again. But if I start at "0x90" it runs until "0xFF".

So I tried to do this also with the firmware-readout function. And very well, if I start at "0x90" there I get values until "0x784" until it stops again. Then some values need to be read out manuall again and another bunch of values can be read out incrementally.

So now I need to investigate why this happens. At first I thought it might be a problem with
th SPI. Maybe that a delay function is too short and something gets mixed up.
Then I tried to prolongue the delay functions, but with no improvement.

Then I thought it might be a buffering / overflow problem. But it always stopps at the same adresses, without any relation to where it was started.

I guess I will try using another MC just to check out if this makes a difference.

I just can't do this manually for 64.000 byte :-/

Sascha