Andy Green wrote: > We go on with MSP430FG4618. Perfect. Pheew, what a battle :-)
Now, on to the two remaining MPU issues: - power supply - programming (as in "loading Flash content") For the power, I'd suggest we take the LDO6 approach as our current working hypothesis. In the unlikely event that we later run into a case where we actually need the MPU to have power even if Vsys is down, we can always tweak go back to exploring the alternatives. Another thing that could kill this approach is if we need LDO6 for some other purpose. In GTA02, it only supplies LCM_3V, which we could probably also just attach to RF_3V (that's the supply for GPS), provided our GPS module has suitable internal gating. We'll also have to look at whether we stay in the total current budget. Does anyone think this is not a good idea, or are there any obvious reasons why this wouldn't work ? On to the programming. There was some discomfort with using JTAG. I think the main objections were: 1) if we connect the JTAG chain improperly, JTAG will not work at all 2) OpenOCD doesn't support the MSP430 3) the JTAG chain grows Are there any other potential issues with using JTAG ? I wonder if 1 is a high-risk item. Connecting those few lines seems simple enough to me and we should be able to eliminate any mistakes in review. Am I overlooking some insidious source of danger ? I'm not sure how bad point 2 is. Would it be really all that hard to add MSP430 Flash programming support ? (We don't need all the debugging features that JTAG also can provide.) Do Linux-based MSP430 developers use JTAG today to program their MSP430 ? If yes, could we use their solution ? Point 3 means that OpenOCD has to be able to deal with a JTAG chain that contains things we're not currently interested in. I don't know if this is a problem for OpenOCD or not. We'd certainly need a new OpenOCD configuration file describing the chain layout. Another effect of having a longer chain would be that shifting data through it takes longer. Also, a longer chain may be more susceptible to bit corruptions or similar errors. Since JTAG is designed precisely for a configuration where all the JTAG-capable devices on a board are in a chain, I wonder how probable it is that these potential issues turn into real ones. What would happen if we didn't have JTAG to program the MPU ? Then we'd either have to establish a "private" access path (test points, special configuration through the FTDI, etc.) to one of the MPU's mechanisms to load the firmware. Alternatively, and I think this is what Andy mentioned as a possibility, we could interface the MPU with the CPU, so that the CPU would connect to these interfaces, and that we'd program the MPU through the CPU. This, however would imply that we can't rely on the MPU to help setting up the PMU. I.e., if a firmware download goes awry, we'd need some alternative unbricking method. We'd also have to provide the tools that implement that alternative programming method over the interfaces we offer. Whether this is easy or incredibly messy depends a lot on where these interfaces are. In any case, it seems to me that creating such a "homebrewn" solution has a much higher risk of unintended consequences, both on the hardware and the software side, than just getting JTAG to work. Long-term, I having JTAG on as many chips as possible would also allow us to do boundary scans as part of our production testing process. I'm not sure how many of the hardware problems we actually encounter in our production could be spotted more efficiently through JTAG than through a different testing process, but I think it's only prudent to keep this option open. Andy, since you'll discuss the MSP430 with Milosch this weekend anyway (duh, it's this weekend, right ? Or was it the last one ? The weeks blur into each other ...), perhaps you could find out what his experience with JTAG there is, and then we can decide on a further course of action. Does this sound good ? - Werner _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
