|
ImDifferent posted:Little microcontroller-based CTF hacking competition: This did not mix well with alcohol, FYI.
|
#
?
Jan 18, 2014 07:49
|
|
|
|
| # ? May 11, 2024 10:38 |
|
|
I need a little utility to dump the flash off a connected MSP430 without disturbing it. This will be run by someone else out in the field, so the less complexity the better. It's totally fine for it to be cygwin->msp430-gcc, but if there's some way for CCS to do this out of the box that would be better. Nothing's jumping out at me besides hopping into debug mode (trashing whatever image is on the flash) and poking through the disassembly. Agents are waiting outside the warehouse and I need to send this interrupt.
|
|
#
?
Jan 22, 2014 20:51
|
|
|
JawnV6 posted:I need a little utility to dump the flash off a connected MSP430 without disturbing it. This will be run by someone else out in the field, so the less complexity the better. It's totally fine for it to be cygwin->msp430-gcc, but if there's some way for CCS to do this out of the box that would be better. IAR EWARM can connect with a debugger without downloading or interrupting execution. You can then halt and save a memory dump. I just uninstalled EW430 so I can't check to see if it has the same options but I would imagine it does. The kickstart edition may be able to do this for you, too. It's worth checking in to.
|
|
#
?
Jan 22, 2014 20:55
|
|
|
Found the magic google words to bring this up: http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer Works for me. Now I need to debug why it keeps crashing after a flash write, but I'm sure it's more of my stupidity.
|
|
#
?
Jan 23, 2014 18:24
|
|
|
What do folks here do for unit testing? I'd like to do more of it than I currently am, but there are some issues that I keep running into:
There are also some "quis custodiat ipsos custodes" issues wrt. the test harness relying on code to dump the report to the LCD and/or an SD card and that code not being bug-free, but those are minor. It seems like there ought to be a better way to do things.
|
|
#
?
Jan 29, 2014 16:11
|
|
|
I'm in a similar camp and would be open to hearing what other people's experience is.
|
|
#
?
Jan 29, 2014 19:55
|
|
|
The key is to stress the cost of bugs caught during fully automated unit testing vs the cost of catching bugs during integration or hardware-in-loop testing. If you can catch all your bugs during functional testing, (which isn't really possible) then you are doing a LOT of that testing. And you're paying someone in India (or even worse, in your own lab) to test every possible combination of button debouncing only to have them accidentally discover an off-by-one loop bug and put it in with a failure report of "Doesn't work." that you now have to track down. All that vs a unit test covering all your boundary conditions that would catch the bug in the time it takes you to go get a cup of coffee, before it ever even makes it into the mainline. Yeah, there's always testing that must be done in hardware with a user or test rig manipulating the electrical or physical environment, but that testing is so many orders of magnitude slower and so many orders of magnitude more expensive than a unit test that you don't want to waste that effort catching pure software stuff. Unfortunately for embedded, as you've noted, it's nowhere near as easy as it is with JUnit/NUnit. Usually everyone's toolchains are different enough you're building something custom. But if your platform supports automating flashing of the code from the command line, and can record a serial data dump from the device of 'pass/fail' with ID# or something, it's doable. I've never seen anything pretty though. I've seen software unit testing done in a simulator, which is the closest to a clean solution you'll find I suppose.
|
|
#
?
Jan 30, 2014 01:15
|
|
|
Otto Skorzeny posted:What do folks here do for unit testing? I'd like to do more of it than I currently am, but there are some issues that I keep running into: Whenever possible, I try to design my libraries so that I can compile them natively on my developer machine with GCC. Then I write unit test suites for the libraries with Unity. This doesn't work for libraries that are tightly-coupled to hardware, but can be a real lifesaver for poo poo like command parsers, communication libraries, etc. I just finished a serial communication library that packetizes, adds error-checking, encodes, and transmits packets of data point-to-point over a UART. It works on a PC as well, because the actual UART byte transmit/receiver functions are left as function pointers. That allowed me to mock them out and write a full unit test suite for the library.
|
|
#
?
Jan 31, 2014 03:48
|
|
|
I think it depends a lot on the code you're talking about. For example, I recently wrote a logger that logged to a NAND flash chip. It had a ton of code because it had to deal with variable size entries, so I needed to maintain a sort of table-of-contents so we could do things like search by timestamps, clear old entries after reading without deleting new entries, etc. For that, I just wrote a mock flash driver and a buttload of unit tests. These didn't test anything related to the driver or the micro-controller, and they ran natively on my dev machine (luckily I'm using a 32-bit microcontroller). The flash device was just represented 4mb char array in memory, and I mocked out functions that accessed it and had the same erasure rules as my device. The driver code on the other hand I didn't really unit test. This was because it was mostly code that shipped bytes around and sent commands to hardware, and it would have been an order of magnitude harder to write unit tests in the conventional sense. However, I did write a low-level interface to the driver code and a bunch of test scripts that communicated with my micro over USB. This let me make sure I understood the flash device correctly and that my mock code would match the driver code's fairly well. As a result of all this, I didn't have to debug any of the "business logic" on the device itself, which would have been really difficult. What errors I did find were mostly minor timing issues or spots where I had misunderstood the data sheet. Plus, when I went back to add stuff much later, I could be fairly certain I wasn't loving things up due to me not remembering details of the (probably overly complex) high-level logic. At a minimum, I would aim for some level of automated testing. User testing is incredibly time-intensive and you will miss stuff. You really need to be writing tests incrementally as you develop code and running them constantly--whether that is unit tests or test scripts that talk to the device directly. evensevenone fucked around with this message at 05:57 on Jan 31, 2014 |
|
#
?
Jan 31, 2014 05:55
|
|
|
So I picked up an Intel Galileo (intel powered Arduino Uno), I am making plans to replace it with something else as the PWM is too slow to relibably use as a servo controller. I am looking at the Beaglebone Black My main concern is that the digital IO pins on the beaglebone black are 3.3v whereas the rest of the industry/ecosystem seems to be heading for 5v It looks like my servos will probably work on 3.3v, but things like my shiftbrite v2 require an input voltage of 5.5v; however I already have a seperate 1.5amp 5.5v power rail - do I only need 3.3v to do the data/control?
|
|
#
?
Feb 2, 2014 20:35
|
|
|
The datasheet is always your best bet when trying to interface chips/systems/whatever. Look at the datasheet for the A6281 (the chip the shiftbrite is based on) and try to find the specs for the logic voltage thresholds. They're named VIH and VIL in the datasheet. In that same table is the power supply requirement, VIN. Putting all three together, what do you think you'll need to do to make the BBB play nicely with the shiftbrite? You need to give the shiftbrite a 5V supply on VIN, but you should be able to directly connect the BBB IO to the shiftbrite. The A6281's VIH is only 2.0V, which will work just fine with the 3.3V IO of the BBB.
|
|
#
?
Feb 2, 2014 21:23
|
|
|
Hadlock posted:So I picked up an Intel Galileo (intel powered Arduino Uno), I am making plans to replace it with something else as the PWM is too slow to relibably use as a servo controller. It's actually the other way, the electronics industry as a whole is largely moving towards 3.3v. It's mostly legacy parts, and things designed for legacy systems that are still designed for 5v. Because of the commonality of 5v logic and 8bit micros hobbyists are somewhat slow to pick it up. EDIT: A note on the beaglebone. If you're going to do any adc reads on it, while the beaglebone as a whole is 3.3v, the ADC only goes up to 1.8v Aurium fucked around with this message at 22:22 on Feb 2, 2014 |
|
#
?
Feb 2, 2014 22:03
|
|
|
Does anyone know of any good open-source embedded software that uses C++ effectively? I'm starting the design of some low-level software, and it occurred to me that outside of UI elements I haven't seen C++ used very effectively in embedded SW. Mostly I've seen instances where it is used, but to such a limited extent that C could have been more easily used instead.
|
|
#
?
Feb 2, 2014 23:34
|
|
|
Slanderer posted:Does anyone know of any good open-source embedded software that uses C++ effectively? I'm starting the design of some low-level software, and it occurred to me that outside of UI elements I haven't seen C++ used very effectively in embedded SW. Mostly I've seen instances where it is used, but to such a limited extent that C could have been more easily used instead. This is mostly because a lot of C++ features have a fair amount of overhead associated with them, which isn't so great for embedded stuff with really tight flash and RAM limitations. Thus, C++ is usually used as "C with classes" for embedded stuff.
|
|
#
?
Feb 2, 2014 23:44
|
|
|
There are some great applications for things like Templates related to nonvolatile storage or shared variables with an RTOS. ChibiOS has a full C++ API, if you're looking for example. Generally though, some of the features are costly in resources (vtables, templates), and some techniques are frowned upon (dynamic memory) in embedded systems.
|
|
#
?
Feb 3, 2014 00:26
|
|
|
For those of you interested in buggy firmware and incomplete hardware libraries (who needs working servos or tone() out??), my Intel Galileo is now up for sale, $10 off, sales tax free and free shipping; make me an offer, I do not like newegg's RMA process http://forums.somethingawful.com/showthread.php?threadid=3606431 My Rhythmic Crotch posted:You need to give the shiftbrite a 5V supply on VIN, but you should be able to directly connect the BBB IO to the shiftbrite. The A6281's VIH is only 2.0V, which will work just fine with the 3.3V IO of the BBB. Thanks, I was reading 5v but I wasn't aware of the difference between VIN vs VIH/VIL
|
|
#
?
Feb 3, 2014 00:39
|
|
|
Most modern 5v logic is .8 low threshold and 2v high. Practically it means that most 5v logic will accept 3.3v logic as an input. Going from a 5v chip to 3.3 you can just use a voltage divider to scale it back down. Lines that are bidirectional are trickier, but there are ICs and simple circuits that can do translation. Of course there are chips that don't accept 3.3v. Some of the 4000 cmos chips need 3.5v as the high threshold when powered from 5v. Most 74hc and hct have a threshold of around 3.15v so they can work, but with that little margin they can be touchy. That number is taken with 4.5v supply, so with a 5v supply it would be slightly higher. Aurium fucked around with this message at 01:21 on Feb 3, 2014 |
|
#
?
Feb 3, 2014 01:15
|
|
|
I'd suggest strongly against using I/O directly on the beaglebone. It's very easy to overvolt it a little bit and cause damage, especially if you're interfacing with a 5V interface. Just use the serial port and give your commands to some kind of really basic PIC (or whatever you like). That way, you can contain the different voltage domain on a fairly isolated circuit.
|
|
#
?
Feb 4, 2014 09:56
|
|
|
I know this thing is not quite up your guys alleys, but it's in the same vein. I thought I might post here before spawning a whole thread for it. I want to do horrid and inappropriate things to flash drive microcontrollers. Basically, I want to see if I can rewrite the firmware to turn them into little embedded computers that I can talk to via serial. The initial idea was spawned by this blog post: http://www.bunniestudios.com/blog/?p=3554 But I'd like to try flash drives rather then SD cards, mostly because that's what I have lying around. However, I'm not adverse to investing in a stack of cheap SD cards if that's easier. Basically the question is, how do I get access to and/or deliver the firmware to the device? Where's my starting point?
|
|
#
?
Feb 4, 2014 13:41
|
|
|
The first step is basically become an expert at USB, then specifically Mass Storage class (which entails learning a lot about SCSI). Next, you'll need to get some sort of inkling as to what micro is on the stick. Then you probably need to be a top-of-the-profession reverse engineer to go further than that. You might luck out and find a part number in there for a micro with a USB device that has exploitable errata. You could try sending vendor specific setup requests to see if you get anything back. Really, once you're here it's either going to be extreme skill, luck, or extreme patience and perseverance.
|
|
#
?
Feb 4, 2014 14:39
|
|
|
Well, I'll just have to roll up my sleeves then! Resources for this kind of thing seem pretty thin on the ground, which is a bit of a shame.
|
|
#
?
Feb 4, 2014 14:50
|
|
|
Markov Chain Chomp posted:I'd suggest strongly against using I/O directly on the beaglebone. It's very easy to overvolt it a little bit and cause damage, especially if you're interfacing with a 5V interface. Just use the serial port and give your commands to some kind of really basic PIC (or whatever you like). That way, you can contain the different voltage domain on a fairly isolated circuit. Good to see you around again, CptMafh 
|
|
#
?
Feb 4, 2014 14:57
|
|
|
Sir_Substance posted:I know this thing is not quite up your guys alleys, but it's in the same vein. I thought I might post here before spawning a whole thread for it. This is a great project and somewhat up my alley and not nearly as doom and gloom as that other dude said. Provided you use SD cards instead of flash drives, however. SD cards are purely driven by SPI, which makes them trivial to communicate with using an Arduino or PIC. I've never looked into the internal structure of flash drives, but the USB addition makes them way less accessible. Look on Alibaba or Aliexpress and see if you can get a handful of 2gb microSD cards for cheap. If you get stuck on any part of this, I'd totally be interested in a thread about it, I might have some ideas on how to proceed.
|
|
#
?
Feb 4, 2014 23:43
|
|
|
USB keys are just SD cards with a sdmmc to usb interface. It's easier to work on SD cards because you don't need to worry about the USB part, but that said you can just circumvent the USB part and talk to the SD card directly with SPI. If you can somehow rewrite the firmware of the usb part you make a nicer interface to it. It would probably easier to replace the usb part with something like a teensy, though.
|
|
#
?
Feb 5, 2014 00:33
|
|
|
When using CCS and working on TI uCs (specifically MSP430 and Piccolo) I notice that using a breakpoint (not sure if its hardware-breakpoint or not, just "breakpoint") and setting it to "Refresh All Windows" to update watched variables, I notice a lot of flickering on the actual device and debug LEDs when it runs. Is this because the breakpoint, although its not supposed to stop the code, is having to do a bunch of work to send the "Refresh!" command back to my computer and eating cycles? Or am I doing it wrong and does Code Composer Studio offer a way to do less destructive updating of watched expressions and watched variables?
|
|
#
?
Feb 5, 2014 00:40
|
|
|
ante posted:This is a great project and somewhat up my alley and not nearly as doom and gloom as that other dude said. This project is pretty exciting because as Bunnie Huang pointed out in his blog post, if someone can develop a limited understand of a popular SD card's chip, it would make a very cheap uC available to hobbyists with lots of onboard storage.
|
|
#
?
Feb 5, 2014 00:42
|
|
|
ante posted:SD cards are purely driven by SPI, which makes them trivial to communicate with using an Arduino or PIC. This isn't quite true - the SD spec defines the (slow as balls) SPI interface to an SD card as well as the much faster parallel SD interface.
|
|
#
?
Feb 5, 2014 00:49
|
|
|
reading posted:When using CCS and working on TI uCs (specifically MSP430 and Piccolo) I notice that using a breakpoint (not sure if its hardware-breakpoint or not, just "breakpoint") and setting it to "Refresh All Windows" to update watched variables, I notice a lot of flickering on the actual device and debug LEDs when it runs. I'm working with Launchpads recently. The connection between the MSP and the 'emulation' side of the board is some 2wire interface with the test and ~rst pins. I'm programming an embedded device with ground, test and ~rst alone. I can't speak to your specific issue, but if you need to get a bunch of variables out of RAM and off the chip, your code can't keep crushing through. Getting a snapshot at that moment of execution requires each value to be sent over that interface. If you're watching the whole memory, my SWAG comes out to .05 seconds as a lower bound.
|
|
#
?
Feb 5, 2014 01:04
|
|
|
reading posted:When using CCS and working on TI uCs (specifically MSP430 and Piccolo) I notice that using a breakpoint (not sure if its hardware-breakpoint or not, just "breakpoint") and setting it to "Refresh All Windows" to update watched variables, I notice a lot of flickering on the actual device and debug LEDs when it runs. What kinds of things are you doing with the piccolo?
|
|
#
?
Feb 5, 2014 01:08
|
|
|
Otto Skorzeny posted:This isn't quite true - the SD spec defines the (slow as balls) SPI interface to an SD card as well as the much faster parallel SD interface. I wrote an SPI interface using PIC about fourish years ago, at that time (as far as I could figure), the only way to get the parallel spec was to pay licensing fees. Regardless, the SPI commands that Bunnie's talking about is straightforward, as I said.
|
|
#
?
Feb 5, 2014 01:46
|
|
|
ante posted:I wrote an SPI interface using PIC about fourish years ago, at that time (as far as I could figure), the only way to get the parallel spec was to pay licensing fees. I would up writing an SPI interface using CortexM3 about a year ago despite my employer having paid the license fees and having the parallel spec in front of me because the hardware guy on the project didn't want to use more pins 
|
|
#
?
Feb 5, 2014 01:53
|
|
|
Otto Skorzeny posted:the hardware guy on the project didn't want to use more pins My hardware guy didn't even give me LED's on the last board. 
|
|
#
?
Feb 5, 2014 02:06
|
|
|
Ok, so for context here, I'm a total software guy. I've played with an arduino once, and that's about it. So here's the next question. SD cards are going to be better to work with because they don't have an extra system between you and their microcontrollers, sounds good. Does accessing the card via a normal USB card reader wipe out that benefit? Will I need a special device to interrogate the card? edit: while we are here, I was having interesting thoughts about using them as hardware encryption keys by generating entropy based on the layout of their bad sectors. Viable? Sir_Substance fucked around with this message at 02:42 on Feb 5, 2014 |
|
#
?
Feb 5, 2014 02:36
|
|
|
Otto Skorzeny posted:I would up writing an SPI interface using CortexM3 about a year ago despite my employer having paid the license fees and having the parallel spec in front of me because the hardware guy on the project didn't want to use more pins You can run the SD spec on the same number of pins as running it in SPI mode and on most CM3s you should be able to run the interface at 24 MHz or 48 MHz if your card supports it. You have to go out of your way to flip a card into a parallel mode. Sir_Substance posted:edit: while we are here, I was having interesting thoughts about using them as hardware encryption keys by generating entropy based on the layout of their bad sectors. Viable? I'm not sure the bad block locations will actually be sufficiently random. Based on the maps we end up with on bare NANDs at work, they tend to cluster a bit. I don't know how much entropy is needed to be cryptographically secure, though. SD cards are a whole different story from bare NAND, and I have no idea if they would exhibit similar patterning. carticket fucked around with this message at 03:18 on Feb 5, 2014 |
|
#
?
Feb 5, 2014 03:15
|
|
|
Sir_Substance posted:Ok, so for context here, I'm a total software guy. I've played with an arduino once, and that's about it. Yes, a reader will wipe out the advantage. You need something that reads and writes directly to the pins in binary. An arduino or maybe a bus pirate would be easier for a software guy
|
|
#
?
Feb 5, 2014 03:35
|
|
|
Sir_Substance posted:Ok, so for context here, I'm a total software guy. I've played with an arduino once, and that's about it. I think you're talking about being able to use the card with an arduino and then later plugging it into a computer.. You certainly wouldn't want to use a usb card reader with an arduino or other uC. Implementing USB host just to read USB mass storage is awfully roundabout when you could skip it. There's no general problem with moving a card between a uC and a computer, but you will need a file system that can be read by both systems. The arduino comes with a library for SD cards that supports both FAT16 and FAT32. You'll also need some kind of holder for the card. (or at least it's easier with something to hold the card) SD cards are 3.3v so depending on your uC you'll need level conversion circuitry. The arduino is 5v, so if you're using that you might just want to buy one of the shields. They tend to have all this built in. Final edit: I went back and reread what you're working on. I'm pretty sure that this isn't what you're trying to do. I'll leave it up, you might find it useful. In any case USB computer interfaces would try hide everything from you. Aurium fucked around with this message at 03:56 on Feb 5, 2014 |
|
#
?
Feb 5, 2014 03:35
|
|
|
So based on what I'm hearing, something like this: http://www.seeedstudio.com/wiki/SD_Card_Shield_V3.0 Stacked onto an arduino uno I have lying around might do the trick? That shield is designed to allow an arduino project to use more memory then is on board, I guess for data logging on similar, but since it's talking about SPI interface pins, it sounds like I might be able with not too much trouble to program the arduino to act as a serially accessible interface to the SPI pins? Also, to clarify the sort of thing I would like to do, I'd basically like to start by seeing if I can make the card act as an admittedly rather slow add on CPU with a fixed function. E.g. you can plug it into a computer, send two bytes to it over SPI using a special driver and it will interpret them as integers and return their sum, or some other such simple task.
|
|
#
?
Feb 5, 2014 04:25
|
|
|
Yup, that would work. Just don't use the SD card libraries at all. Or maybe use them but hack them to send the altered commands that you want to send. If you could find the same brand of card from the link above, it would make your life easier, but if not you might be able to brute-force it.
ante fucked around with this message at 05:44 on Feb 5, 2014 |
|
#
?
Feb 5, 2014 05:39
|
|
|
Yeah I would start by going through some SD driver or that library to see the CMDs it sends, their response, and how it gets the card in specific modes. I had to write something for work that hacked the linux driver to init with a different set of commands. This set of commands was a backdoor to the emmc firmware so that we could flash new firmware.
|
|
#
?
Feb 5, 2014 06:10
|
|
|
|
| # ? May 11, 2024 10:38 |
|
|
Sir_Substance posted:edit: while we are here, I was having interesting thoughts about using them as hardware encryption keys by generating entropy based on the layout of their bad sectors. Viable? Viable in the sense of "could I do that?" Yes. Viable in the sense of "is this a good idea?" No.
|
|
#
?
Feb 5, 2014 06:13
|
|
