^^ Instead of using the key GPIO lines as I suggested above, another less intrusive option would be to use the exposed pads at the back. In that case, we would need a small PIC/Atmel chip connected to the SWCLK and SWDIO pins, using a I2C serial interface. That chip could then be used to bridge any external circuits. In fact, that chip could even be used to flash the custom firmware itself, dispensing with a programmer! So, one possible cool project is to create an “expansion” module for the PO, allowing any number of “custom” hardware modifications.
@masterofstuff124 - if you have not already you should check out Nicolas Collins hardware hacking book, it has lots of info about the stuff you mention.
@punji - you are the man. I watch with interest 
Hi people any advancements in this post? Maybe we can use some code from http://bastl-instruments.github.io/bastl/ ?
I have started putting together a basic firmware for STK-3800 + little prototype board I showed above as a proof of concept. I also recently reverse engineered and documented the PO-16 LCD display mapping. Unfortunately, I could not spend as many hours as I would like on that project lately, so it will take a little longer to get some code running.
Also, I’m not entirely sure about the end goal here anymore. It will be hard to replicate all the PO functionality and create new engines and effects as good as the original ones from TE. Reusing code from other projects may prove difficult, unless they also target a fixed point architecture, preferable Cortex-M3. Not sure about the bastl code above, but Teensy seems to require Cortex-M4 (floating point).
The expansion module idea would bring a significant differential from the original POs, but it will require developing a small PCB with a secondary micro-controller to interface with the EFM32, connected to the exposed pads at the back with pogo pins. That would allow some cool projects, like adding a MIDI interface to the POs, or some mixed analog/digital circuits (besides being able to flash the firmware without a dev kit), but it would also require lot of additional work (i.e., in addition to developing a new firmware).
At the end, I may likely just publish a basic framework code for the POs at github and see if more people get some interested in contributing to it…
@punji If you ever need any indications in that matter, one very cool feature would be to save and load PO patterns.
Do you think, with you actual knowledge of the hardware, that one can reach that ?
@LyingDalai I confirmed a while ago that the debug interface was locked by TE for the original firmware, so we can’t access the EFM32 internal flash where the presets are stored. The only option is to load a new firmware and use something like Korg did for the Volcas, i.e., export/import the data as a wav file using the audio in/out.
Excuse my ignorance @punji-masta, I was kinda hoping there would be some difference between the ROM-like firmware and the changing patterns.
Would you mind explaining me why it doesn’t work like this, program and saved data separate ?
I have so no clue what I’m talking about that I feel like I’m asking noob questions even if I wrote programs for years…
:B
@LyingDalai If you look at http://hackingthepo.weebly.com you may see all the components inside the PO. There is no dedicated flash chip for the patterns, i.e., all the flash memory is inside the EFM32 chip and it is used to store both program code and user data. So, when you store a pattern, the PO code running on the EFM32 just copies the data from RAM to a reserved area in the internal flash. Now, TE has chosen to set a protection bit when factory flashing the firmware, otherwise we would be able to use the STK dev kit to read everything, including the PO code and patterns.
I personally think TE should have included a wav based pattern backup. Each pattern takes just 1KB of memory (educated guess). At those sizes they could have used something as simple as the ZX Spectrum tape transfer protocol, even if it would take about 1 minute to transfer all the 16 patterns.
Oh man how far I am from embed prog… I should dive into it one day
So :
- is protected firmware impossible to hack ? What kind of protection is it btw ? I mean if it’s kind of low level programming, with stack operations and such stuff, how can the chip operate protected code ? The firmware has to be read to be executed, how does it work with protected firmware ?
- by comparing the firmware before and after a pattern saving, one should get some info on the saving of patterns. Can’t this special area been hacked ?
Just tell me to return playing with my OP-1 if my questions get you annoyed or even pissed off, I have no clue if I am trying to dig the ocean with a spoon or what 
Thanks for your answers so far !
@LyingDalai Your questions are welcome… I do realise that most people on this forum are not familiar with those concepts.
The EFM32 firmware protection is done at HW (silicon) level. The dev kit debug interface can be used to access the EFM32 internal memory bus to read/write the flash contents. That same interface can also be used to set the protection bit, which will then completelly disable external access to the memory bus. There is no way to reset that bit, unless a full flash erase is performed first. It is usually not possible to hack that, unless the chip is vulnerable to some attack, like using a high voltage spark to glitch the internal circuits and bypass the protection. In fact, it would be very bad for Silicon Labs, the manufacturer of the EFM32 chip, if such vulnerability was found, so they probably took measures against that.
1 Like
Damn, I read a bit here and there, apart a short window at startup to reset the flash memory I haven’t found anything about cracking the protection…
I understand that there is write protection, and lock.
For the later, one can only erase the memory and reload the firmware.
Another way would be to spy outgoing/incoming messages and guess the operations performed. Brute stuff…
Can’t one spy the evolution of the 128K memory in real time ?
Or let’s bribe @Jon ^^
^ Maybe the NSA has some tools to do that…
hey all
i just saw te twitter retweeted this Teenage Engineering PO12 HACK - YouTube
i was hoping it was gonna use the programming (or whatever) port on the back but it seems it’s just been soldered into each switch. interesting idea anyway.
keep up the good work @punji! i see you’ve added the factory (right?) lcd details to your site. i would like to get involved in programming an alternative firmware for one of these things too, i’m doing exams at the minute but over summer i’ll have more free time. i’ve programmed arm before in college too so i’m hoping that will help.
I think the idea above is brilliant : one can imagine a MIDI interface controlling the triggers and knobs the hard way, with soldering and all.
This is definitely an interesting path.
^^
I plan to do that pretty much when I get my hands on a PO. I have a padKontrol and I’m thinking I’ll just use the gpio on an r.pi I have.
Good to hear that you want to help @naraic! Yes, I have recently reverse engineered the PO-14 display and should soon be able to do the same for the PO-12 that is about to arrive. In fact, a lot has happened these last few days… I was able to run some basic code on the STK3800+prototype board for processing the keys and pots, generate the sequencer clock, blink the LED and play a sine wave tone through the Cirrus Logic DAC using the CMSIS math/DSP library. That gave me encouragement to flash my PO-16 with some code to help probing the board circuits. That has validated the PO flasing procedure using a EFM32 Starter kit and the cable connections described in my weebly site. I now have the complete mapping from the EFM32 pins to the various board components.
Next step is to start implementing the new PO firmware!
wow! you’ve made so much progress, that’s really impressive.
how legal is reverse engineering these kinda things? 
^ I don’t know much about legal aspects of reverse engineering, but I think in this case it is “fair use” because I have no intention of reproducing the original HW (which could have design patents), just reflash a device that I bought from TE. Note that I have absolutely no access to the original firmware, so I can’t be accused of copying it.
Go punji! The progress is great to read! Keep up the good work!