MicroHacker Forum

I think you have to define this addresses in your tool - at 17 you write the EEPROM address, then starting with 30 you write the FLASH addresses.

i read from 0x0000 to 0xFFFF and i get a 62kb file, i need to find a tool to convert s19 to hex at the moment im using the vbftool as i dont know anyother tool that converts s19 to hex then remove header and save as bin

i so far can find a lot of similarity to the dump and ford firmware possibly a start

after doing some research on the web i found these settings read the full chip
i can also write this back to the module and verify


had to put the dump in a zip as it wouldn't let me upload the s19 file

i have found i can import this to HxD editor but it seems to put tons of 00 bytes in between each block of data

Those addresses look weird to me. They don't match the PDF of 9S12D64 (which match the software I use; I've gave you a screenshot from it).

If you read it several times it gives you the same values? ... You might also read some RAM values.. and these ones should change between readouts.

DGAlexandru wrote: ↑29 Aug 2022, 05:10 Those addresses look weird to me. They don't match the PDF of 9S12D64 (which match the software I use; I've gave you a screenshot from it).

If you read it several times it gives you the same values? ... You might also read some RAM values.. and these ones should change between readouts.

When I put in the addresses from the screenshot it's the same data in each block

I have just checked with the settings I found and file same every time

Gwe89 wrote: ↑27 Aug 2022, 21:05@Go4IT

So, what i do in this case is to open the VBF in VBF Tool, and export the data with "File -> ExportToFile -> Motorola...". This will generate an "s19" file that can be imported (!) with HxD. This kind of file remains the addresses.

There is other valuable information in the header of the VBF files.

AM2J-14C280-AB.vbf: The "erase" block tells you where the parts of VBF will be stored. These are also the areas to read back from the programmed chip.
The "sw_part_type" tells EXE for the main software.

AM2J-14C405-AA.vbf:
contains a sw_part_type of "SIGCFG", looks like configuration data which is stored here: And 6G9N-14C282-AA.vbf:
Is the secondary bootloader, as "sw_part_type = SBL" shows
Other than the other parts this is only stored in RAM not Flash, therefore you find no "erase" block.
But the VBF tells you the entrypoint of the software: For you to dump the chip, you can skip the SBL.

DGAlexandru wrote: ↑27 Aug 2022, 21:35 based on HC/MC 912 / 9S12 and never broke them by connecting only GND, RST and BKGD.

Yes, i agree that it better.

Gwe89 wrote: ↑27 Aug 2022, 22:30 I'm still learning here

Besides of electronics you should learn to void uneccessary quotes. It makes not sense to quote the whole text of another person and just add a sentence. Please try to be more specific in your quotes, remove parts that are not needed to understand the answer/question. That helps making posts more readable. THX

DGAlexandru wrote: ↑29 Aug 2022, 05:10 Those addresses look weird to me. They don't match the PDF of 9S12D64 (which match the software I use; I've gave you a screenshot from it).

That's because he is using a differnt tool (USBDM) than you (XProg?). USBDM is more related to the hardware. It uses the default memory map, or the one programmed in the INIT sequence. This Sequence simply set the register RR (given as hex) to the value VV (given as hex), which looks like this:
(RR,VV)
or
(RR1,VV1,RR2,VV2,...)

If you don't check the "Paged Flash" box, it will use linear memory addresses (0x0000-0xFFFF as it is only 16 bit address range). As all the other chips of this family, it therefore uses paging. It will put (map) a page set in the page register 0x30 to the variable page window address at 0x8000. This "window" is capable of showing 16kb of Flash.
This is denoted in you screenshot as "Page $30: 08000 - 0BFFF" and the following. They just put a different counter into the PPAGE register and so map another page into the same memory window.
In USBDM the desired PAGE is put as part of the address, like in your tool. So the first byte will put to PPAGE register. It is just different counting of page-IDs.

Beside the variable parts, they are also two fixed parts:
- the first flash page is always mapped to 0x4000-7FFF
- the last flash page is always mapped to 0xC000-FFFF (in fact it only uses up to 0xFEFF to not overwrite reset vectors which starts at 0xFF00)
See memory layout from datasheet: As the chip only has 64KB of Flash, this makes 4 PPAGEs. The first and the last is always mapped, so it makes no sense to put it into page window. This leaves it to 2 additional pages. The page-ID of the first page is always 0x3E (63 dec.) and the last 0x3F (64 dec.). The other pages are counted downwards from 0x3D. So 0x3D should be the third page and 0x3C the second page. This will result in addresses for USBDM like:
0x3C8000 - 0x3CBFFF
0x3D8000 - 0x3DBFFF
To get the first page he just puts
0x4000 - 0x7FFF
and for the last page
0xC000 - 0xFEFF

This way, Gwe89 has copy-pasted the right values in. (the "width" has no meaning and can also be set to "1")
What he got after readout is the full reflection of the chips Flash memory.
To get the rest of the firmware, he of course could read the entire 64kb range of the chip: 0x0000-0xFFFF
Which i would suggest.

The tricky part is to slice the parts of the VBF files to the correct PPAGEs when programming them back.
Excactly the same is to be done for the EEPROM content.

The programmer of USBDM was so kind to add more values and a load/save functionality on my request, thanks for that!

[quote=DGAlexandru post_id=3393 time=1661749802 user_id=70]

This way, Gwe89 has copy-pasted the right values in. (the "width" has no meaning and can also be set to "1") What he got after readout is the full reflection of the chips Flash memory. To get the rest of the firmware, he of course could read the entire 64kb range of the chip: 0x0000-0xFFFF Which i would suggest.

So is my read out a full read as it let's me write it back to it, if the file is not 64kb it won't allow me to write it says it won't fit onto memory range something along those lines


Added:: if I read from 0x0000-0xFFFF I get a smaller file which I can't write back to the module