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

0 Members and 2 Guests are viewing this topic.

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #475 on: January 19, 2019, 08:32:21 am »
The assembler was contributed by Nicolas Lesser. I just merged a patch by him that fixes this issue.
Philipp

What would be the best way to get feedback and patches to him? I found and fixed a bug in enconding SL/SLC/SR/SRC. Fix attached.

 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #476 on: January 19, 2019, 03:10:39 pm »
The assembler was contributed by Nicolas Lesser. I just merged a patch by him that fixes this issue.
Philipp

What would be the best way to get feedback and patches to him? I found and fixed a bug in enconding SL/SLC/SR/SRC. Fix attached.

To get the patches to him, I'd suggest opening an issue or pull request at his repo:

https://github.com/Rakete1111/sdcc-pdk

Alternatively, you can open a ticket in the SDCC patch tracker, from where an SDCC developer (e.g. me) would apply it to the assembler in the SDCC pdk branch:

https://sourceforge.net/p/sdcc/patches/

Philipp
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #477 on: January 19, 2019, 03:16:27 pm »
Added you to free-pdk organization on github*.

Thanks a lot! I will put the programming protocol information there.

Btw, in general:

It seems like every other padauk device is using a different programming algorithm. So far, only two are known: PFS154 ("5-wire", confirmed twice), PMS150C ("six-wire". The PMC150C algorithm also works on the PMS154C, when changing datalen.

I tried a couple of other device:
   - PMC251 uses six-wire physical interface, but was unresponsitve with the PMC150C algorithm
   - PMS131 uses an eight-wire physical interface and seven when in an 8-pin package

It could get quite tedious to also decode all devices. Hopefully all MTP devices will use the 5-wire protocol.

How about the PFS173? From the datasheet it looks as if it uses the same pins as the PFS154.
On the other hand, my information on the PFC232 and PFS232 indicates that these two use an interface different from the PFS154, and PA4 has a role in programming them (for a total of 6 pins in the interface).

Philipp
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #478 on: January 19, 2019, 04:00:49 pm »

To get the patches to him, I'd suggest opening an issue or pull request at his repo:

https://github.com/Rakete1111/sdcc-pdk

Thanks, done!

How about the PFS173? From the datasheet it looks as if it uses the same pins as the PFS154.
On the other hand, my information on the PFC232 and PFS232 indicates that these two use an interface different from the PFS154, and PA4 has a role in programming them (for a total of 6 pins in the interface).

Just guessing: PFS173 and PFS154 are probably identical, since the adresslength is sufficient. No ideay about the PFC/PFS232, I have not seen any datasheet.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #479 on: January 19, 2019, 11:39:40 pm »
I assembled the 2 PCBs of my "easy pdk programmer" today.

- complete design process was done using EasyEDA + JLPCB  + LCSC.
- learning how to use EasyEDA was very easy
- ordering on JLPCB was smooth and very good price ($2 for 10 PCBs, if you panelize then you might get 40 programmer PCBs for just $2 + shipping)
- ordering components at LCSC based on EasyEDA BOM was also very easy, they offer to combine shipment with JLPCB so you pay shipping ($5 for normal delivery) only once.
- it only took 8 days from ordering PCB + components till arrival *wow*

- both assembled boards are working (tested basic functions: generate +15V, dual DAC+opamp can output specific voltages, USB ok, LEDs ok, button ok, ...)
- only 1 small mistake on test PCB (forgot to connect something to ground, was easy to fix with a jumper wire)

I will test programing a PFS154 and some other ICs within the next days. Hopefully getting everything ready before chinese new year starts (China closes on 30th of January for 2-3 weeks).

JS

P.S. I will upload schematics, gerber and firmware sources to github as soon as the stable programmer is confirmed working.

PPS:

The PCB on top of the picture is having the optional 4 pin SWD header for easy debugging. The PCB on bottom is having an optional GND pin for easy oscilloscope measurements. Both of this optional components are not required for normal operation of the programmer later.
The missing components are caused by choosing a different DCDC booster and by getting rid of the not required level shifter.
« Last Edit: January 19, 2019, 11:44:22 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: ebclr, rhodges

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #480 on: January 20, 2019, 01:01:15 pm »
- both assembled boards are working (tested basic functions: generate +15V, dual DAC+opamp can output specific voltages, USB ok, LEDs ok, button ok, ...)
- only 1 small mistake on test PCB (forgot to connect something to ground, was easy to fix with a jumper wire)
Nice!

May I suggest one addition for the next revision of the board:

Add another row of 8 holes in 2.54mm raster, spaced 15.24mm (6 rows in 2.54mm raster) from the current one. Connect all the holes to GND.

This would allow to later create small adapter pcbs, which can then be securely plugged on top of the programmer with pin header sockets. In these adapter pcbs you can then plug in programming sockets for the Padauk controllers.

See here for details of the idea: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2105053/#msg2105053
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #481 on: January 20, 2019, 02:10:31 pm »
Nice!

May I suggest one addition for the next revision of the board:

Add another row of 8 holes in 2.54mm raster, spaced 15.24mm (6 rows in 2.54mm raster) from the current one. Connect all the holes to GND.

This would allow to later create small adapter pcbs, which can then be securely plugged on top of the programmer with pin header sockets. In these adapter pcbs you can then plug in programming sockets for the Padauk controllers.

See here for details of the idea: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2105053/#msg2105053

My initial idea was to go sideways.
I already created a small adapter PCB with a ZIF20 DIP small socket which can get connected to the 8 pins directly but also has pin header for every pin of the ZIF20 socket so it can be used as a generic adapter with jumper wires. This allows all PADAUK ICs to be written regardless of the pinout.
There are many cheap adapters from TSOP to DIP which  can be used easily in the ZIF20 socket.

Anyway I also like the on top idea. But new problems will arise like can not see LEDs or reach user button anymore, ...

I will do some experiments and report back here. Several ZIF TSOP and adapter PCBs are on the way to me now.


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

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #482 on: January 20, 2019, 02:35:22 pm »
My initial idea was to go sideways.
Yes, that would also work. But in my experience sideways going female headers (the ones that would go on the next pcb to the side) are more expensive and more rare than the straight ones. That is why I'd prefer to go on top.
 
I already created a small adapter PCB with a ZIF20 DIP small socket which can get connected to the 8 pins directly but also has pin header for every pin of the ZIF20 socket so it can be used as a generic adapter with jumper wires. This allows all PADAUK ICs to be written regardless of the pinout.
Jumper wires are ok during programmer development. But I'd like to avoid them for regular use afterwards: they tend to create EMI problems and sometimes make bad contacts. So I'd prefer a solution with adapter pcbs which are made for one kind of Padauk controller. You can fit a lot of different ones on one 10x10 pcb.

Anyway I also like the on top idea. But new problems will arise like can not see LEDs or reach user button anymore, ...
You could move the button to where the URL text is now.

BTW, what do you plan to use the button for?

I'd also suggest to add another button connected BOOT0 to boot with the integrated usb bootloader. That way you don't need a SWD programmer for initial programming. This would make it easier for people to make their own padauk programmers when they don't regularly use STM32 or other controllers with SWD interface.
« Last Edit: January 20, 2019, 02:41:25 pm by electronic_eel »
 

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 866
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #483 on: January 20, 2019, 03:29:31 pm »
Quote
Posts: 101
Country: ht
View Profile  Personal Message (Offline)

Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #479 on: Yesterday at 10:39:40 am »
Say ThanksReplyQuote
I assembled the 2 PCBs of my "easy pdk programmer" today.

- complete design process was done using EasyEDA + JLPCB  + LCSC.
- learning how to use EasyEDA was very easy
- ordering on JLPCB was smooth and very good price ($2 for 10 PCBs, if you panelize then you might get 40 programmer PCBs for just $2 + shipping)
- ordering components at LCSC based on EasyEDA BOM was also very easy, they offer to combine shipment with JLPCB so you pay shipping ($5 for normal delivery) only once.
- it only took 8 days from ordering PCB + components till arrival *wow*

- both assembled boards are working (tested basic functions: generate +15V, dual DAC+opamp can output specific voltages, USB ok, LEDs ok, button ok, ...)
- only 1 small mistake on test PCB (forgot to connect something to ground, was easy to fix with a jumper wire)

I will test programing a PFS154 and some other ICs within the next days. Hopefully getting everything ready before chinese new year starts (China closes on 30th of January for 2-3 weeks).

JS

P.S. I will upload schematics, gerber and firmware sources to github as soon as the stable programmer is confirmed working.

PPS:

The PCB on top of the picture is having the optional 4 pin SWD header for easy debugging. The PCB on bottom is having an optional GND pin for easy oscilloscope measurements. Both of this optional components are not required for normal operation of the programmer later.
The missing components are caused by choosing a different DCDC booster and by getting rid of the not required level shifter.

Great work :-+ :-+ :-+
I can do the schematic and PCB in Altium too! after you release the stable version. ;)
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #484 on: January 20, 2019, 04:36:26 pm »
I'd also suggest to add another button connected BOOT0 to boot with the integrated usb bootloader. That way you don't need a SWD programmer for initial programming. This would make it easier for people to make their own padauk programmers when they don't regularly use STM32 or other controllers with SWD interface.

Having the serial bootloader accessible would be nice, but it missing is not a deal breaker.

You can use any Linux SBC's GPIO with openocd to do debugging over JTAG/SWD. It is very likely that anyone adventurous enough to look at Padauk MCUs will have a raspberry pi lying around.

A script (or self contained appimage) that does the flashing with a single command would be nice, though.

Enviado de meu SM-N910C usando o Tapatalk

 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #485 on: January 20, 2019, 04:51:09 pm »
My initial idea was to go sideways.
Yes, that would also work. But in my experience sideways going female headers (the ones that would go on the next pcb to the side) are more expensive and more rare than the straight ones. That is why I'd prefer to go on top.
I found femal sideways header on LCSC (you are right, it was tricky).

I already created a small adapter PCB with a ZIF20 DIP small socket which can get connected to the 8 pins directly but also has pin header for every pin of the ZIF20 socket so it can be used as a generic adapter with jumper wires. This allows all PADAUK ICs to be written regardless of the pinout.
Jumper wires are ok during programmer development. But I'd like to avoid them for regular use afterwards: they tend to create EMI problems and sometimes make bad contacts. So I'd prefer a solution with adapter pcbs which are made for one kind of Padauk controller. You can fit a lot of different ones on one 10x10 pcb.
A lot of changes are requested/required (e.g. mounting holes, adapter on top, ...) I will see how much I can put into it.

Anyway I also like the on top idea. But new problems will arise like can not see LEDs or reach user button anymore, ...
You could move the button to where the URL text is now.
BTW, what do you plan to use the button for?
Was just a thought. Like the original PADAUK programmer. Maybe later you can transfer the image to programmer and then press the button to program (no need of computer).

I'd also suggest to add another button connected BOOT0 to boot with the integrated usb bootloader. That way you don't need a SWD programmer for initial programming. This would make it easier for people to make their own padauk programmers when they don't regularly use STM32 or other controllers with SWD interface.
Will do that, I try to connect the user button also to BOOT0.

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

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #486 on: January 20, 2019, 04:59:12 pm »
Having the serial bootloader accessible would be nice, but it missing is not a deal breaker.
Since ST-LinkV2 (china clone) costs less than $2 there is really no point anymore to use the serial boot loader.
For the price of just a USB serial adapter you get a full featured SWD debugger which opens the REAL world of software development (fast uploading, breakpoints, watched variables, ...).

I only can strongly recommend to switch to real software development (use JTAG/SWD and a debugger) and avoid the "printf debugging" introduced by Arduino.
Setting up and learning how to use the free open source tool chains for real development and debugging is dead simply nowadays. And it is possible to use all Arduino libraries and sample code.
Just ditch the Arduino IDE!

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

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #487 on: January 20, 2019, 05:37:30 pm »
A lot of changes are requested/required (e.g. mounting holes, adapter on top, ...) I will see how much I can put into it.
I offer to make some adapter pcbs for different padauk ics and publish the sources & gerbers for others to use. So no extra work for you creating adapter pcbs. But I'll wait for you to publish a programmer layout with holder pins first.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #488 on: January 21, 2019, 08:41:46 pm »
I assembled the 2 PCBs of my "easy pdk programmer" today.
...
I will test programing a PFS154 and some other ICs within the next days. Hopefully getting everything ready before chinese new year starts (China closes on 30th of January for 2-3 weeks).
Great work, very clean build!

Any success with programming so far? :)

I only can strongly recommend to switch to real software development (use JTAG/SWD and a debugger) and avoid the "printf debugging" introduced by Arduino.
Setting up and learning how to use the free open source tool chains for real development and debugging is dead simply nowadays. And it is possible to use all Arduino libraries and sample code.
Just ditch the Arduino IDE!

Well, it looks like we are stuck with "printf debugging" with the Padauk controllers though. One thing I implemented was to use the programming interface as an SPI backchannel. The "programmer" (I am referring to my breadboard contraption) is resetting the MCU and is then listening to SPI transmissions on the programming interface lines as a slave. This allowed some degree of debugging. This may be an interesting addition to the firmware of your programmer as well.



« Last Edit: January 21, 2019, 08:50:19 pm by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #489 on: January 21, 2019, 08:48:16 pm »
FYI, I worked on more assembler code based on the OSS toolchain, mainly using SDASPDK. You can find some examples for the PFS154 here:

https://github.com/cpldcpu/SimPad/tree/master/PFS154Examples

They are tested on actual hardware.

"blinkyasm.c" should assemble with the current version of SDASPDK from Phillips branch. The other examples need the patch that I posted above. It is on it's way upstream, though.

Edit: Just noticed, the patch is already there. Looks like I need a cron job to update SDCC :)




« Last Edit: January 21, 2019, 09:10:56 pm by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #490 on: January 22, 2019, 11:55:33 am »
Any success with programming so far? :)
Not much time right now. I just got ADC working properly (was mistake with a resistor in schematic). Next part is trying to reduce ripple (everything is a bit noisy right now so I will play a bit with different cap values / adding some caps).

For programing I'm swapping pins around so the hardware SPI and a complete TIM is available on right pins.

Well, it looks like we are stuck with "printf debugging" with the Padauk controllers though. One thing I implemented was to use the programming interface as an SPI backchannel. The "programmer" (I am referring to my breadboard contraption) is resetting the MCU and is then listening to SPI transmissions on the programming interface lines as a slave. This allowed some degree of debugging. This may be an interesting addition to the firmware of your programmer as well.

Excellent idea / addition. This can be added to the programmer USB protocol as a debug channel.

But do you think SPI is a good choice? I used it in a previous test and had the problem that if a single bit was missing (e.g. after startup) the complete output was garbled.
spth made a small demo with a very simple UART. Maybe we should choose this method as it can handle transmission errors more easy (e.g. require 2 stop bits and we can resync).
Or we use SPI with CS(NSS) but then 1 more wire required.

JS

UPDATE:
This is the hardware mapping I have available after swapping pins:

STM_PB3: SPI1_SCK  / TIM2_CH2      (IC_PA3)
STM_PB4: SPI1_MISO / TIM3_CH1     (IC_PA4)
STM_PB5: SPI1_MOSI / TIM3_CH2     (IC_PA6)   (SPI slave mode on STM uses MOSI to get data from IC)
STM_PB6: UART1_TX  / TIM16_CH1N (IC_PA0)
STM_PB7: UART1_RX  / TIM17_CH1N (IC_PA7)


* IC_PA3 requires to have the SPI1_SCK, also the dedicated TIM is required to capture input pulses during calibration (note: TIM2 additional channels can not be shared with PWM or other functions)
* IC_PA4 requires SPI1_MISO (input of IC <= output of STM32)
* IC_PA6 requires SPI1_MOSI (output of IC => input to STM32)
* UART1_TX / UART1_RX can be used for debugging and also for serial boot loader of STM32, no special requirement for IC pins
« Last Edit: January 22, 2019, 03:29:42 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #491 on: January 22, 2019, 01:02:56 pm »
But do you think SPI is a good choice? I used it in a previous test and had the problem that if a single bit was missing (e.g. after startup) the complete output was garbled.
spth made a small demo with a very simple UART. Maybe we should choose this method as it can handle transmission errors more easy (e.g. require 2 stop bits and we can resync).
Or we use SPI with CS(NSS) but then 1 more wire required.
I have bad experience with several kinds of CS-less SPI variants. You need a mechanism like CS, otherwise your transfer quickly becomes unreliable.

I'd much prefer a software UART for debugging. You just need one TX line and that's it, no additional clock or CS. Also you wouldn't necessarily need the programmer to read the output, any UART dongle will do. So you also wouldn't need any code for it in the programmer firmware (but it wouldn't hurt of course if someone wants to write it).

The only problem could be to detect the correct baud rate as the internal clock of the Padauk could be off. So I suggest to send a 0x55 ("U") character first. It has a 10101... pattern and is commonly used for autobaud mechanisms.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #492 on: January 22, 2019, 08:45:41 pm »
Yes, I agree, an UART would be much nicer. I was not sure how much the clock in my devices was miscalibrated, so it was much quicker to implement SPI. I worked around the misalignment issue by introducing a timeout.

Having an UART with autobaud would be the best option, but it's a bit more involved to implement this on host side. How would you do bitrate detection? By bitbanging? Or oversampling with DMA?
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 187
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #493 on: January 22, 2019, 09:29:01 pm »
Having an UART with autobaud would be the best option, but it's a bit more involved to implement this on host side. How would you do bitrate detection? By bitbanging? Or oversampling with DMA?
The STM32 have autobaud hardware, see AN4908: https://www.st.com/content/ccc/resource/technical/document/application_note/group0/66/fa/62/a2/5c/75/48/a8/DM00327191/files/DM00327191.pdf/jcr:content/translations/en.DM00327191.pdf

On the STM32F072 only UART1 and 2 have autobaud, so the TX pin of the Padauk should be connected to any of these pins on the STM32: PA3(*), PA10, PA15, PB7
(*) TTa Analog IO, pin is only allowed to go up to 3.3V, so we'd need an extra buffer ic in between to protect the pin from 5V.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #494 on: January 23, 2019, 09:01:16 pm »
I adapted SDAS to PDK13, so it is now also possible to use a OSS toolchain for the true "$0.03 MCU". Not sure whether this will be available upstream anytime soon, as there is still some work to be done to allow PDK13 and PDK14 to coexist in SDCC. (Frankly, that is probably the harder part...)

In any case, I uploaded some (verified) code examples here:
https://github.com/cpldcpu/SimPad/tree/master/PMS150CExamples

 

Offline _echo

  • Newbie
  • Posts: 1
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #495 on: January 26, 2019, 12:11:52 am »
On the topic of VPP generation there is a family of parts that might be useful if you happen to have them handy and have a breakout board.
There are specialty(ish) DACs called programmable gamma buffers such as the ISL76534.

They can be referenced to a quite high voltage (up to 19V), configured over i2c, and have fairly good current capability (for a DAC).

My plan is to build up a programmer using the PGB + cheap boost module from aliexpress as the VPP/VDD generator. By setting setting the boost converter to output 16.384V, the math is also simpler making runtime vpp/vdd calculation possible.

Nothing against the host MCU generated PWM scheme, it's certainly economical. IMHO, those boost modules are cheap enough to use as the source of high voltage, and eliminates the risk of getting the boost converter stuck when doing ISP of the AVR.

Still waiting for my chips to come in before I confirm that these parts can be programmed with this guy providing power.

Regards
_echo
 
The following users thanked this post: oPossum

Offline socram

  • Regular Contributor
  • *
  • Posts: 62
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #496 on: January 26, 2019, 02:30:25 am »
Getting the PWM stuck isn't really that much of a problem. The ISP runs on reset, and on reset all pins are set as inputs and PWMs are stopped.

Regarding my programmer, I have finally settled on the following:

It will be made with all DIP parts, to make prototyping and soldering for newbies easier. Still, given how few components this have it won't be too big.

The MCU is gonna be an ATtiny84A running at 20MHz, which I received yesterday. This part is tiny (14 pins), cheap (~1€ each), yet has all the features I need for this: two PWM, two DAC inputs and enough flash/RAM for V-USB. It's also available in both DIP and SMD packages, both from LCSC and from western providers such as Mouser or RS.

I'll be using V-USB with HID for controlling the programming sequence. This means no driver needed on either Windows or Linux. It also means the firmware will be self-updating using any computer with no specialized programmer thanks to the Micronucleus bootloader I've previously tried and used.

After considering the original buck+linear, the buck+boost design, and the SEPIC design, I'm gonna go with a pair of completely independent SEPIC DC-DC converter for voltage generation. SEPIC means I will be needing a single PWM channel, thus simplifying a lot the algorithm for keeping the voltage supply stable, and a single MOSFET for controlling an output from all the way to zero when stopped, up to about 9V.

I'm waiting to receive the MOSFETs and Schottky diodes from LCSC. Will keep you updated guys.
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #497 on: January 26, 2019, 07:41:43 pm »
I adapted SDAS to PDK13, so it is now also possible to use a OSS toolchain for the true "$0.03 MCU". Not sure whether this will be available upstream anytime soon, as there is still some work to be done to allow PDK13 and PDK14 to coexist in SDCC. (Frankly, that is probably the harder part...)

Where can I find this sdas for pdk13? How is the target selected? An assembler directive similar to how ".cs08" switches the hc08 assembler to s08 mode and .hd64 switches the z80 assembler to z180 mode?

Philipp
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #498 on: January 26, 2019, 08:57:35 pm »

Where can I find this sdas for pdk13? How is the target selected? An assembler directive similar to how ".cs08" switches the hc08 assembler to s08 mode and .hd64 switches the z80 assembler to z180 mode?

Philipp


I linked it in an issue in Nicolas fork of SDCC.

https://github.com/Rakete1111/sdcc-pdk/issues

He seems to be busy though. I simply modified the existing source to support PDK13 instead of PDK14. I made no attempts to create a switch or similar. That is probably something that someone who is more familiar with the structure of SDAS should do. I also found additional bugs in PDK14.

« Last Edit: January 26, 2019, 09:01:54 pm by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
STT/LDT instruction encoding
« Reply #499 on: January 27, 2019, 08:43:13 am »
Code: [Select]
0 0 0 0 1 1 c 7-bit MEM addr c 16 bit memory operations
0x03.. 0 0 0 0 1 1 0 M 0 STT16 M M ← Timer16 (last bit of M set to 0, M must be word aligned)
0x03.. 0 0 0 0 1 1 0 M 1 LDT16 M Timer16 ← M (last bit of M set to 1, M must be word aligned)

One question about the STT/LDT instruction encoding: The bitfield for the memory address is only 7 bits instead of 8. Which bit of the address is discarded? The MSB or LSB? Since the adress is word-aligned, it should be fine to discard the LSB.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf