Dash Hacking: Bare-Metal STM32 Programming
learn.adafruit.com
learn.adafruit.com
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.
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.
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.
http://www.mouser.com/ProductDetail/STMicroelectronics/STM32...
In the Europe, there's Farnell:
http://www.newark.com/stmicroelectronics/stm32f411e-disco/de...
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.
Selecting which mode to use is a simple matter of setting a specific value at a specific position in the Flash image, very handy.
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.
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.
We disabled the debugger that we had on the UART, though. We're not totally crazy.
Just getting something working out the door is challenging enough. Firmware always comes in hot.