Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering  (Read 67133 times)

1v0n and 4 Guests are viewing this topic.

Offline spth

  • Regular Contributor
  • *
  • Posts: 82
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #725 on: September 30, 2019, 04:15:44 pm »
I can only corroberate JS findings about very bad noise immunity of the PFS154.

I wasted a lof time getting a LED to work as a light sensor on the PFS154. My only conclusion is that the PFS154 has severe internal coupling issues. I summarized my findings here:

https://cpldcpu.wordpress.com/2019/09/28/a-led-candle-based-on-the-3-cent-mcu/

It seems to be advised to stick to purely digital designs, at least for the lower end Padauk MCUs.

Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #726 on: October 02, 2019, 05:47:14 am »
Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

Yeah, it's kinda telling if the manufacturer mentions it even on their line card. Although, bad PSRR/EMI immunity does not neccesarily imply that there is also strong internal coupling. In this case it seems to be like that.

I wonder, has anybody tried the ADC in the PFS173 yet? How many bits are actually noise free?
« Last Edit: October 02, 2019, 06:06:23 am by tim_ »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #727 on: October 03, 2019, 06:37:06 pm »
I've tried setting the last word but it seems there's some kind of either protection or sorcery going on - I cannot change it to anything:

Code: [Select]
> write-pfs154.py honk.ihx com3
Writing 0000-0007... done
Writing 0010-00AB... done
Writing 07FF-07FF... done
Verifying 0000-0007... OK
Verifying 0010-00AB... OK
Verifying 07FF-07FF... FAILED
@ 07FF - expected 0000, read 3FFF

I have VPP set to 5.8V and the rest of the flash seems to be programmable just fine. Should I do anything special to program this last word?
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #728 on: October 04, 2019, 09:44:55 am »
I've tried setting the last word but it seems there's some kind of either protection or sorcery going on - I cannot change it to anything:

Code: [Select]
> write-pfs154.py honk.ihx com3
Writing 0000-0007... done
Writing 0010-00AB... done
Writing 07FF-07FF... done
Verifying 0000-0007... OK
Verifying 0010-00AB... OK
Verifying 07FF-07FF... FAILED
@ 07FF - expected 0000, read 3FFF

I have VPP set to 5.8V and the rest of the flash seems to be programmable just fine. Should I do anything special to program this last word?

There is no magic for last word. It looks like your programmer / programming script tries to write to odd address. PFS devices only can start writing at even addresses (this means you have to write 7FE and 7FF, you can write "FFFF" to 7FE so it will not change the exisiting value, just the verifier in your script needs to know about this fact afterwards).

JS
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: socram

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #729 on: October 04, 2019, 09:49:53 am »
Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

Yeah, it's kinda telling if the manufacturer mentions it even on their line card. Although, bad PSRR/EMI immunity does not neccesarily imply that there is also strong internal coupling. In this case it seems to be like that.

I wonder, has anybody tried the ADC in the PFS173 yet? How many bits are actually noise free?

I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #730 on: October 04, 2019, 10:03:29 am »
There is no magic for last word. It looks like your programmer / programming script tries to write to odd address. PFS devices only can start writing at even addresses (this means you have to write 7FE and 7FF, you can write "FFFF" to 7FE so it will not change the exisiting value, just the verifier in your script needs to know about this fact afterwards).

JS
Thank you! I will try to have my programmer align to chunks of 4 words.

EDIT: that did the job! Thank you again!
« Last Edit: October 04, 2019, 10:42:26 am by socram »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #731 on: October 04, 2019, 01:28:35 pm »
As oposed to what https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt says, the LVR seems not to be configured via the last word but the MISC_LVR register:

For 4.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x00
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.5V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x20
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x40
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.75V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x60
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.5V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x80
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 1.8V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xA0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.2V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xC0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xE0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #732 on: October 04, 2019, 01:54:56 pm »
I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS

Thats a very good offer. How did you manage to order there?

I tried to investigate the PFS173 ADC only to find that ASPDK15 does not encode the SWAPC instruciton correctly, which is used in my softuart. Took quite a while to find this. Ticket to SDCC is submitted. Obviously, SDCC never generates a SWAPC, so it is not covered in the regression tests...


« Last Edit: October 04, 2019, 02:01:12 pm by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #733 on: October 04, 2019, 06:38:01 pm »
As oposed to what https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt says, the LVR seems not to be configured via the last word but the MISC_LVR register:

For 4.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x00
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.5V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x20
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x40
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.75V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x60
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.5V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0x80
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 1.8V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xA0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.2V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xC0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.0V:
Code: [Select]
0x0007:   0x2fe0    MOV A, 0xE0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

Depends on the IC. The raw (very early) notes reference PMC154B with some similarities from PFS154. PMC154B does not have MISC_LVR register.

A better way is to use the original IDE, play with the "code options" for your specific CPU and document the results.
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #734 on: October 04, 2019, 06:41:59 pm »
I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS

Thats a very good offer. How did you manage to order there?


I know some local guys ordering it for me and forward it.

But now that we know it exists: It is possible to query LCSC.com to get special parts which they do not have in inventory...
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #735 on: October 06, 2019, 09:46:12 am »
Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #736 on: October 06, 2019, 10:29:37 am »
Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.

It's called like that in the official include for from the IDE (PFC154.INC), see below. The underscore does not fit to general conventions indeed.

JS has included the underscore in the defines.
https://github.com/free-pdk/easy-pdk-programmer-software/blob/master/Examples/src/easypdk/pfs154.h#L195

Code: [Select]

MISC_LVR IO_WO:OP 0x1B (-)
$ 7 ~ 4 : 1V8, 1V9, 2V, 2V1, 2V2, 2V3, 2V4, 2V5, 2V75, 3V, 3V15, 3V3, 3V5, 3V75, 4V, 4V5
$ 1 ~ 0 : BG_On, BG/4, BG/32, BG_Auto
 

Offline itelite

  • Contributor
  • Posts: 21
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #737 on: October 07, 2019, 07:20:18 pm »
Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.  I have the PMS150 on a breakout board stuck into a bread board, with the intent to run jumper wires from the headers to the breadboard.  Any guidance would be appreciated.

 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #738 on: October 07, 2019, 08:12:19 pm »
Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.
It is documented vaguely in the datasheets and manual for the official programmer from Padauk. You'd have to read several of the controller datasheets, the protocol description in this thread and on github and then slowly the pieces begin to fall together.

But I also made an adapter pcb which should make it easy: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/adapter-pcbs. You could replicate that on your breadboard. See the schematics. The inner columns are the programmer, the outer ones the Padauk.
 

Offline chaplin

  • Newbie
  • Posts: 2
  • Country: cn
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #739 on: October 08, 2019, 03:26:00 am »
hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
850414-0
this my board pic

any idea what might goes wrong?
« Last Edit: October 08, 2019, 08:59:57 am by chaplin »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #740 on: October 08, 2019, 04:13:19 pm »
hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS



Easy PDK programmer and more: https://free-pdk.github.io
 

Offline itelite

  • Contributor
  • Posts: 21
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #741 on: October 08, 2019, 04:18:26 pm »
Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.
It is documented vaguely in the datasheets and manual for the official programmer from Padauk. You'd have to read several of the controller datasheets, the protocol description in this thread and on github and then slowly the pieces begin to fall together.

But I also made an adapter pcb which should make it easy: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/adapter-pcbs. You could replicate that on your breadboard. See the schematics. The inner columns are the programmer, the outer ones the Padauk.


Oh ok good.  I can work with that.  I just realized based on the photos in the above post that the pins are meant to be marked on the PCB.  The silkscreening on my PCB is so bad that it all looks like smudges ha.  Thats what threw me for sure.

 

Offline chaplin

  • Newbie
  • Posts: 2
  • Country: cn
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #742 on: October 09, 2019, 08:57:06 am »
hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS
thanks JS,
I made a test board,  only PFS173 and Female Socket were soldered. I also checked   C2 / C10,C13 / C21 , and they were correct.
851040-0
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #743 on: October 09, 2019, 03:56:49 pm »
hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS
thanks JS,
I made a test board,  only PFS173 and Female Socket were soldered. I also checked   C2 / C10,C13 / C21 , and they were correct.
(Attachment Link)

Hi,

On your test board you added more capacitors. This can cause the problem. With additional caps VPP and VDD might need more time / need to be a tiny bit higher to stabilize.
Could you try your extra test board without the capacitors?

Also which version of the programmer software + firmware do you use?
Latest 1.1 version (https://github.com/free-pdk/easy-pdk-programmer-software/releases) contains some improvements regarding writing of PFS173.

JS
« Last Edit: October 09, 2019, 03:59:50 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline itelite

  • Contributor
  • Posts: 21
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #744 on: October 09, 2019, 07:32:10 pm »
ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

 

Offline spth

  • Regular Contributor
  • *
  • Posts: 82
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #745 on: October 10, 2019, 07:17:53 am »
ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

As mentioned before, the symptoms could be due to too much capacitance across VDD or sue to the user of an older version of the programmer software.
The programmer should work fine with the Padauk-recommended maximum of 0.01 µF though.

.ihx is Intel Hex, a rather common format (SDCC emits .ihx by default; the Padauk Mini-C IDE uses some weird obfuscated non-standard thing instead).
« Last Edit: October 10, 2019, 07:23:04 am by spth »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #746 on: October 10, 2019, 12:34:58 pm »
ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

Hi,

can you try to read the written IC and check what was actually written?

You also can disable the blank check and try to write the IC again with the same file (see command line option of easypdkprog: --noblankchk). In case some bits not been written in the first run this can fix this situation.

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #747 on: October 10, 2019, 04:17:52 pm »
Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.

Your argument with "MISC_LVR_DISABLE" confliction with "misc_lvr" register name was a good one.

I changed "_misc_lvr" to "_misclvr" and all its defines to "MISCLVR_...".

I also added defines in capital letters for all registers so Visual Studio Code can syntax highlight them (as suggested by @tim_). So for example the "_misc_lvr" register can be accessed by "MISCLVR" now, like: MISCLVR = MISCLVR_3V | MISCLVR_BANDGAP_AUTO;

(In development branch of programmer software, examples folder: https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Examples/src)

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline itelite

  • Contributor
  • Posts: 21
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #748 on: October 10, 2019, 05:20:40 pm »
I can read successfully and it has been written.  not sure how to compare it to input, since input is a IHX file, readout seems to do a HEX file or a BIN file.

no blank check yields a successful write and failed verify. Even running several times.

What is the hello world supposed to do? That is to say, how can i test that it is functioning? i assume a hello world over serial, but this does not happen.

Wirelength is about 10CM.  Anyway to slow down programming, in case wire length is an issue? it could be 100X slower and that would be just fine with me.
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 82
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #749 on: October 11, 2019, 06:55:11 am »
I can read successfully and it has been written.  not sure how to compare it to input, since input is a IHX file, readout seems to do a HEX file or a BIN file.

.ihx and .hex are both file endings for Intel Hex. objcopy can be used to convert between Intel Hex and raw binary.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf