New Dev Platform for MSP430FR5969

[igor 163]

Regarding the micro-board - that one is totally up for grabs.  We started with "small", 0.1" spacing and CR2032 for a prototype, but all of the above could change.  I agree - it would be great to leverage another micro-format and the CR2032 is cramping our style there.  That said - most of the other modules out there aren't low power enough to run on a CR2032.  There is a sea of products out there that can easily run off a CR2032 - I'd like to leverage them and build an ultra-low-power toolbox, for the same reason as using the TI FRAM processors.  Maybe I'm just not seeing the existing products, but I think there's a big gap in this area in general.  Do you perceive any of the products you mentioned as having enough traction to support and help expand as a standard format?

Afraid I don't know enough about the particular platforms to have an opinion - merely observed that there are a lot of them. It seems like 0.7inches wide is particularly common (I assume that these boards probably have a similar spacing between pin headers, related to breadboard spacing). So seems like one would want to either match that spacing, or go for something sufficiently different that an adapter is easy to do.

 

The XBee compatibility is definitely worth looking into.  Again - no way even the 1mW radio could run off a CR2032 (50mA TX), but it's pretty well established and I'm sure would have good crossover in potential applications.  The size is also probably the closest of any existing format.

Wasn't necessarily meaning to suggest using the same socket. Just to think about how an adapter from your device to XBee would work.

 

Solar is something we'd like to play with too.  You could run a datalogger off a tiny panel and a supercap.  Add a radio and you start to need a panel bigger than the board and probably a small rechargable, but yes - certainly within the realm of the possible.  If you only need daylight operation, I'm sure a tiny panel would be enough for many applications.  Is there an application you had in mind for Solar?

I was thinking about a soil moisture sensor (e.g. to remind gardeners when time to get out and water). It need only run during the day. It doesn't need to wake up very often (updating a few times per day would be sufficient). Soil moisture sensing could be capacitive, or resistive, or .... (Measuring temperature might be a useful addition.) Output goes to an LED (active daytime only), output pin, or radio.

 

What do you guys think about adding a low power accelerometer to the processor board?  RTC or pin wake-ups cover a lot of ground, but having an accelerometer that can wake it up would be useful in a lot of portable applications I would think.  You could power it directly off an IO pin so you could kill it completely if you don't want it.  Freescale's MMA8652FC is pretty slick and not too pricey (~$0.80 @ 100).  Seems like that might be a worthy addition for a low power focused board.

Looks like you lose 1 pin (plus the cost of the sensor) if you don't use it?

How long would the board run on a coin cell with this as a wakeup?

 

While I can think of applications for something like this, seems like main tradeoff may be are you going for low price or lots of built in features. (i.e. how much of a % cost increase does this represent).

It probably wouldn't be cheap/small enough for most of the uses that come to my mind initially.

[pabigot 355]

@@nathancrum Ok, that's a bit more plausible (well, not the power graph).  I suspect it's also pretty highly tuned, and sensitive to what AP was used and possibly whether the responding node was the AP or a third host.  There's also the issue of use cases where the node needs to receive data asynchronously.  The RN171 data sheet doesn't mention whether it supports IEEE PowerSave mode; if not, you're looking at continuous draw of 40mA which gives you a lifespan of maybe three weeks, or doing transmission scheduling at the application layer.

 

At any rate, I'm not saying there aren't cases where WiFi is the best solution, but if your goal is ultra-low-power it's not the technology of choice.  An option for either 802.15.4 or a fully-controllable sub-GHz radio would make the board more attractive to some of us.  As an example, right now I'm aiming for a small-scale deployment with the EXP430F5529-LP and the Anaren booster packs, using a BeagleBone Black with a CC1101 plugged into an RFEM cape to bridge to IP, exposing all the radio functionality to a POSIX development environment through a custom Linux driver.  (I'm not an EE and am dangerous with a soldering iron, so if I can't buy it ready-to-plug-together it's not a platform I can develop to.)

[nathancrum 21]

FYI - first dev prototypes are built.  The processor module is fine, but we're still debugging the ezfet lite circuitry - getting this error when connected to CCS:

"Error initializing emulator: Could not set device Vcc"

Don't know what's wrong.  The programmer is basically a pin-for-pin copy of the ezfet lite reference using a 3.3V regulator.  We flashed it using the MSP430Flasher command line tool, the EZFET_LITE_Rev1_1_FW_3_3_0_6 firmware and an FR5969 Launchpad via SBW.  It seems to work, but generates a verification error and then we get the above error on connecting to CCS.  

 

Is there something separate we have to do with the BSL or is that part of the production firmware?  We're basically stumped at this point.  Any help would be appreciated.

[spirilis 1,265]

that's an odd error, 'cause the eZFET can't adjust Vcc anyhow (it's a feature only reserved for the pricey FET430UIF and MSP-FET).

[abecedarian 330]

Tried a newer version of the MSP430flasher / firmware?

[nathancrum 21]

@@abecedarian Used the latest (I think) version of the flasher.  1.3.2

 

@@spirilis Yea - very annoying.  We must be doing something wrong.  The eZFET lite ref. schematic shows 4 voltages for the reg from 2.8 to 3.6V so I assume all of those would be ok for the voltage checks using the ADC.  We're using 3.3V.  Voltage on Pin 1 and 2 from the voltage dividers both look fine.  We've been struggling with this a couple days - ready to throw in the towel.  Can't figure out what's wrong.

[pabigot 355]

That error comes from the MSPDebug stack. There are three locations in the latest release that error is produced. Since it's open source, I'd download and build that locally, reproduce the problem with mspdebug, then instrument the source code to figure out what conditions cause it to occur. Should be a clue in there somewhere.

[spirilis 1,265]

@@abecedarian Used the latest (I think) version of the flasher.  1.3.2

 

@@spirilis Yea - very annoying.  We must be doing something wrong.  The eZFET lite ref. schematic shows 4 voltages for the reg from 2.8 to 3.6V so I assume all of those would be ok for the voltage checks using the ADC.  We're using 3.3V.  Voltage on Pin 1 and 2 from the voltage dividers both look fine.  We've been struggling with this a couple days - ready to throw in the towel.  Can't figure out what's wrong.

Under Windows? If not, made sure you tried it as root? Used the firmware updater to install the initial firmware and everything?

 

I think @@greeeg has made an ezfet board before...

[nathancrum 21]

@@spirilis  Yep - we're 100% winblows.  Tried reflashing all the ezfet lite firmwares.  The 3V6_TEST firmware lites up the error LED, but all the rest of the test firmwares don't, so power seems ok and it is definitely being flashed with the ezfet on the FR5969 Launchpad...

 

Our setup is basically identical to @@greeeg - would love to hear any ideas from him.  We used the MSP430Flasher_1.3.2 to write the BSL and then flash the EZFET_LITE_Rev1_1_FW_3_3_0_6 firmware...still no love.

[greeeg 460]

@@nathancrum, you need to flash the BSL to allow the ezFET to update itself. If that isn't there, the FET behaves strangely since it continues on with 2 different firmwares on the PC&FET.

 

Are you using the bsl/flash unlock flag when flashing the BSL?

[nathancrum 21]

Yea - we missed that the first time we flashed, but later found it - used it - same error - no change unfortunately.

[greeeg 460]

Have you tried reading back the FW+BSL to ensure that its what you've written?

Note: You need to set the BSL flag again, just to read for that memory location.

 

Do you mind sharing the schematic for this part of your board? Or PM it to me, I'll check it against mine.

[nathancrum 21]

Attached is the schematic.  It probably looks pretty *cough* familiar.  

Storm Ninja Base PCB Schematic.pdf

[greeeg 460]

The thing you want to be able to do is upgrade the ezFETs firmware from MSPFlasher. that's the real key. The firmware you flashed, atleast when I checked, was different to the latest MSPDebug stack firmware. So MSPFlasher SHOULD be telling you to update.

 

Try downloading an older version of MSPFlasher and connecting to the ezFET. if it don't want you to upgrade the FET firmware then something is going wrong. This system is designed so that the PC and the FET both have equal firmware and they both can communicate.

 

At first glance the schematic looks fine. The official ezFET lite down't have 100k resistors for the voltage dividers, that MIGHT be a place of concern.

 

 

As another debug step, try using older versions of the MSPFlasher software. Try to get the one that matches the firmware file you flashed, as a good place to start.

 

 

 

For reference here is the programmer I made. http://forum.43oh.com/topic/5530-custom-ezfet-lite/

[spirilis 1,265]

What VID/PID shows up with your ezfet BSL?