7 ms·

Dash Hacking: Bare-Metal STM32 Programming

46 points by ptorrone 11y ago

chatman 11y ago
This seems like a great alternative to programming an ESP8266.
- tdicola 11y ago
  Yeah if details of configuring the WICED SDK can be sorted out then it would be a nice little wifi & internet connected board. You have to register an account to download it but if you're curious the WICED SDK is here: http://community.broadcom.com/community/wiced-wifi http://community.broadcom.com/community/wiced-wifi
bcg1 11y ago
This is great. I just thinking about messing with a STM32 chip for a project, so this guide looks good. And actually Amazon's little button thing looks awesome. Hopefully they don't freak out and try to lock it down in the future :( Since Microsoft got pwned when they tried to mess with the Adafruit crew you'd think they wouldn't, but I've learned that one should never underestimate the power of human stupidity.
- duskwuff 11y ago
  If you just want to get into development, ST's "Discovery" development boards are really cheap -- like, $10 to $15. Highly recommended.
  - pantalaimon 11y ago
    It also runs Linux https://github.com/AdrianHuang/stm32f429-linux-builder https://github.com/AdrianHuang/stm32f429-linux-builder
    - bcg1 11y ago
      Awesome, and thank you both :)
  - danesparza 11y ago
    Any suggested purchasing outlets? I'm a hardware newbie -- I have no idea where to get my hands on something like this.
    - duskwuff 11y ago
      In the US, Mouser is a solid option: http://www.mouser.com/ProductDetail/STMicroelectronics/STM32F411E-DISCO http://www.mouser.com/ProductDetail/STMicroelectronics/STM32... In the Europe, there's Farnell: http://www.newark.com/stmicroelectronics/stm32f411e-disco/dev-board-stm32f411ve-stm32-discovery/dp/31Y4736 http://www.newark.com/stmicroelectronics/stm32f411e-disco/de...
gcb0 11y ago
the amazon thing is not cheap. for 15 you get a Dev board with lots of handy usb and serial ports. for 5 you get Chinese board with wifi that also have stm32 chips
desdiv 11y ago
Dumb question: why don't manufacturers disable the JTAG interface after all the flashing and testing are done? Don't get me wrong, I really appreciate them leaving these devices easily reprogrammable for us hackers, but there's really not much benefit in it for them.
- stephen_g 11y ago
  Our company leaves them enabled 1) because it's not really worth the effort to disable and 2) it's super handy if you get a product returned to re-flash it if it's somehow been bricked!
  - m_eiman 11y ago
    We use NXP MCUs that have a few different code protection modes. The mode we use in release code disables JTAG and Flash access, but allows erasing the entire Flash. This makes it hard(er?) to read and modify our code, while still allowing us to easily wipe a returned device and re-program it using a suitable firmware image. Selecting which mode to use is a simple matter of setting a specific value at a specific position in the Flash image, very handy.
    - duskwuff 11y ago
      The STM32F2 MCU that Amazon used supports similar features; see section 2.6.3 of: http://www.st.com/web/en/resource/technical/document/programming_manual/CD00233952.pdf http://www.st.com/web/en/resource/technical/document/program... In brief, though, the MCU can be put into "level 1" read protection which limits the capabilities of a JTAG debugger, or "level 2", which fully protects the device by disabling JTAG entirely. Given that Adafruit were able to reprogram the device, Amazon must not have used level 2 protection.
- VLM 11y ago
  There's two parts, the interface on the chip and the easy plugin connection. The interface on the chip can sometimes be disabled in software permanently by various flags when the chip is programmed, but that makes it impossible to troubleshoot something that got returned for failure analysis. Of course some mfgr work around that by never performing any sort of failure analysis or troubleshooting or customer service bug reports of any sort... As for the very convenient jtag port itself each PCB revision costs a substantial amount of time and money and "just rip out these traces and only these traces" as the last step invariably will screw something else up (whoops that JTAG ground pin was actually a via to the I2C bus ground, now the device is dead until the next PCB revision, this is getting very expensive and time consuming). Also faith in the software being finalized and debugged before the final hardware revision is very gratifying, but somewhat unrealistic. Unless you disable the port on the chip itself all you really do it annoy people into soldering wire wrap wires directly to pins, which is easy. (Its hard to get in, there must be something "amazing" in here to get at) Finally the EE world is full of hilarious incredibly expensive stories of mfgrs changing one tiny little bit here or there and not feeling its worth informing the buyers, then suddenly every board with an IC date code over a certain number fails and its costing the company $50K/hr or even worse they shipped and its killing reputation until some EE debugs the problem (oh ha ha sorry about that we didn't think anyone would notice we changed the hardware reset default on that IO pin from pull up to tristate after reset, your software wasn't depending on the unset default was it? oh so sorry to hear.). Slowing the engineer down by intentionally making it harder to debug the board is a great strategy to encourage your competitors to use. We're a little behind you guys, can't you take out your jtag port or somethin so we can catch up on the stuff that matters? After someone ships you a batch of bad/fake chips and "we could prove the chip is a fake or remarked with some other spec but we don't have a jtag connector to really prove it so they'll just have to trust us at the trial" and suddenly your lawsuit gets that much harder to win. Doesn't have to come to a lawsuit even just customer support with the mfgr. Its like chopping the keyboard, mouse, and monitor cable off a server for security, thats funny, but good luck getting support when the raid card breaks and you don't have a keyboard or monitor anymore and they ask you to run a simple diagnostic on the raid card. Its kind of the old DRM argument, how do I distribute encrypted video or whatever and the key to decrypt the video along with it while somehow not letting people access the key, well that's easy, you don't, outside marketing material and lies told to licensed IP holders. (Oh yeah man, chill, don't worry, nobody gonna steal your precious bits to implement your "... on the internet" patent because our jtag is upside down from everyone elses, nobody could eeeever figure that out, your bits are safe) There is no way to keep someone out of hardware they own if there is one person on the entire internet who owns a soldering iron and is motivated enough to use it. You vs the world, good luck with that. The countermeasures that can be attempted are expensive and time consuming yet won't even slow down serious opponents, but trying to implement them WILL impact your financials putting you at a serious measurable disadvantage compared to a competitor who leaves the jtag port ready to use. In summary there's no way to do it, pitiful snake oil-ish attempts that will not work waste a lot of time and money, so its only really viable in non-competitive markets or as security theater to make non-techies happy.
IshKebab 11y ago
The title should reference the Dash really, since that is the interesting bit here; not the STM32 stuff. Anyway, if anyone is going to attempt this I would recommend: 1. Don't install a VM to do this as weirdly recommended in the artcle. Using GCC Arm Embedded on Windows is not difficult. There are pre-built binaries on Launchpad which work fine. 2. If possible, use the mBed API instead of any manufacturer-supplied SDKs. It's a great API and supports many STM32 chips already (though apparently not this specific one so some porting may be necessary). 3. Good luck getting that broadcom wifi chip to work.
- bcg1 11y ago
  I think doing it in a VM for this type of tutorial is not a bad decision. We're at a point where you can't assume everyone uses Windows, and writing up how to do this on every operating system would be a PITA I imagine. As a GNU/Linux user I'm appreciative of this format because I can just ignorant the vagrant stuff and get down to brass tacks.
- davelnewton 11y ago
  A VM, perhaps w/ a Docker image, totally makes sense for this, IMO.

46 points by ptorrone 11y ago

chatman 11y ago

This seems like a great alternative to programming an ESP8266.

tdicola 11y ago
Yeah if details of configuring the WICED SDK can be sorted out then it would be a nice little wifi & internet connected board. You have to register an account to download it but if you're curious the WICED SDK is here: http://community.broadcom.com/community/wiced-wifi http://community.broadcom.com/community/wiced-wifi

bcg1 11y ago

This is great. I just thinking about messing with a STM32 chip for a project, so this guide looks good. And actually Amazon's little button thing looks awesome. Hopefully they don't freak out and try to lock it down in the future :( Since Microsoft got pwned when they tried to mess with the Adafruit crew you'd think they wouldn't, but I've learned that one should never underestimate the power of human stupidity.

duskwuff 11y ago
If you just want to get into development, ST's "Discovery" development boards are really cheap -- like, $10 to $15. Highly recommended.
- pantalaimon 11y ago
  It also runs Linux https://github.com/AdrianHuang/stm32f429-linux-builder https://github.com/AdrianHuang/stm32f429-linux-builder
  - bcg1 11y ago
    Awesome, and thank you both :)
- danesparza 11y ago
  Any suggested purchasing outlets? I'm a hardware newbie -- I have no idea where to get my hands on something like this.
  - duskwuff 11y ago
    In the US, Mouser is a solid option: http://www.mouser.com/ProductDetail/STMicroelectronics/STM32F411E-DISCO http://www.mouser.com/ProductDetail/STMicroelectronics/STM32... In the Europe, there's Farnell: http://www.newark.com/stmicroelectronics/stm32f411e-disco/dev-board-stm32f411ve-stm32-discovery/dp/31Y4736 http://www.newark.com/stmicroelectronics/stm32f411e-disco/de...

gcb0 11y ago

the amazon thing is not cheap. for 15 you get a Dev board with lots of handy usb and serial ports. for 5 you get Chinese board with wifi that also have stm32 chips

desdiv 11y ago

Dumb question: why don't manufacturers disable the JTAG interface after all the flashing and testing are done? Don't get me wrong, I really appreciate them leaving these devices easily reprogrammable for us hackers, but there's really not much benefit in it for them.

stephen_g 11y ago
Our company leaves them enabled 1) because it's not really worth the effort to disable and 2) it's super handy if you get a product returned to re-flash it if it's somehow been bricked!
- m_eiman 11y ago
  We use NXP MCUs that have a few different code protection modes. The mode we use in release code disables JTAG and Flash access, but allows erasing the entire Flash. This makes it hard(er?) to read and modify our code, while still allowing us to easily wipe a returned device and re-program it using a suitable firmware image. Selecting which mode to use is a simple matter of setting a specific value at a specific position in the Flash image, very handy.
  - duskwuff 11y ago
    The STM32F2 MCU that Amazon used supports similar features; see section 2.6.3 of: http://www.st.com/web/en/resource/technical/document/programming_manual/CD00233952.pdf http://www.st.com/web/en/resource/technical/document/program... In brief, though, the MCU can be put into "level 1" read protection which limits the capabilities of a JTAG debugger, or "level 2", which fully protects the device by disabling JTAG entirely. Given that Adafruit were able to reprogram the device, Amazon must not have used level 2 protection.
VLM 11y ago
There's two parts, the interface on the chip and the easy plugin connection. The interface on the chip can sometimes be disabled in software permanently by various flags when the chip is programmed, but that makes it impossible to troubleshoot something that got returned for failure analysis. Of course some mfgr work around that by never performing any sort of failure analysis or troubleshooting or customer service bug reports of any sort... As for the very convenient jtag port itself each PCB revision costs a substantial amount of time and money and "just rip out these traces and only these traces" as the last step invariably will screw something else up (whoops that JTAG ground pin was actually a via to the I2C bus ground, now the device is dead until the next PCB revision, this is getting very expensive and time consuming). Also faith in the software being finalized and debugged before the final hardware revision is very gratifying, but somewhat unrealistic. Unless you disable the port on the chip itself all you really do it annoy people into soldering wire wrap wires directly to pins, which is easy. (Its hard to get in, there must be something "amazing" in here to get at) Finally the EE world is full of hilarious incredibly expensive stories of mfgrs changing one tiny little bit here or there and not feeling its worth informing the buyers, then suddenly every board with an IC date code over a certain number fails and its costing the company $50K/hr or even worse they shipped and its killing reputation until some EE debugs the problem (oh ha ha sorry about that we didn't think anyone would notice we changed the hardware reset default on that IO pin from pull up to tristate after reset, your software wasn't depending on the unset default was it? oh so sorry to hear.). Slowing the engineer down by intentionally making it harder to debug the board is a great strategy to encourage your competitors to use. We're a little behind you guys, can't you take out your jtag port or somethin so we can catch up on the stuff that matters? After someone ships you a batch of bad/fake chips and "we could prove the chip is a fake or remarked with some other spec but we don't have a jtag connector to really prove it so they'll just have to trust us at the trial" and suddenly your lawsuit gets that much harder to win. Doesn't have to come to a lawsuit even just customer support with the mfgr. Its like chopping the keyboard, mouse, and monitor cable off a server for security, thats funny, but good luck getting support when the raid card breaks and you don't have a keyboard or monitor anymore and they ask you to run a simple diagnostic on the raid card. Its kind of the old DRM argument, how do I distribute encrypted video or whatever and the key to decrypt the video along with it while somehow not letting people access the key, well that's easy, you don't, outside marketing material and lies told to licensed IP holders. (Oh yeah man, chill, don't worry, nobody gonna steal your precious bits to implement your "... on the internet" patent because our jtag is upside down from everyone elses, nobody could eeeever figure that out, your bits are safe) There is no way to keep someone out of hardware they own if there is one person on the entire internet who owns a soldering iron and is motivated enough to use it. You vs the world, good luck with that. The countermeasures that can be attempted are expensive and time consuming yet won't even slow down serious opponents, but trying to implement them WILL impact your financials putting you at a serious measurable disadvantage compared to a competitor who leaves the jtag port ready to use. In summary there's no way to do it, pitiful snake oil-ish attempts that will not work waste a lot of time and money, so its only really viable in non-competitive markets or as security theater to make non-techies happy.

IshKebab 11y ago

The title should reference the Dash really, since that is the interesting bit here; not the STM32 stuff. Anyway, if anyone is going to attempt this I would recommend: 1. Don't install a VM to do this as weirdly recommended in the artcle. Using GCC Arm Embedded on Windows is not difficult. There are pre-built binaries on Launchpad which work fine. 2. If possible, use the mBed API instead of any manufacturer-supplied SDKs. It's a great API and supports many STM32 chips already (though apparently not this specific one so some porting may be necessary). 3. Good luck getting that broadcom wifi chip to work.

bcg1 11y ago
I think doing it in a VM for this type of tutorial is not a bad decision. We're at a point where you can't assume everyone uses Windows, and writing up how to do this on every operating system would be a PITA I imagine. As a GNU/Linux user I'm appreciative of this format because I can just ignorant the vagrant stuff and get down to brass tacks.
davelnewton 11y ago
A VM, perhaps w/ a Docker image, totally makes sense for this, IMO.