Chris is the 4.2.2.2 firmware source posted?  I think what is on the download page is for 4.2.2.1.

I likes to keep up-to-date....

oh cool, so you have a working system to compare against; that will be a helpful sanity check when diagnosing problems.

 

BTW, If you happen to see in your spi'ing, a case where an asynchronous event is reported before a command's return packet, let me know.  the doc is not clear about whether that can or cannot happen.

WOW.  I have a long weekend coming up and I know what I will be doing now!  ...

 

Haha, have phun hacking!

 

...

I completely agree with the managed approach.  It reminds me of the enc28j60 driver that Hanzibal ported from C.  When I saw the raw packets coming in, my eyes lit up and I knew it was doable to do everything managed.  And the debugging was much easier because of it.  Once we have the communication and the ..

 

I'm very impressed you and hanzibal got a tcp stack and ethernet device driver working in managed on netmf.  Thats a lot of work.

 

...

command message objects, we should be able to take it all the way.  One thing that could accelerate things greatly would be if I can get just get raw packets to work, I can bolt on mIP and immediately have a usable solution.  To me the next step would be to leverage the cc3000 TCP stack to offload the work to improve ...

My only concern with the managed approach is future changes to the cc3000 firmware and hardware may also require changes in the wrapper (but that is likely to be minimal).  

 

I'm somehow sceptical that you'll be able to get raw packets, but my understanding of this device is far from comprehensive, so don't take my word for it.  (I think it's whole raison detre is to present a high-level berkeley sockets-esque api, so that's why I'm doubtful about that).  But no matter, it will make the job 'easier' to not have to fiddle with windows, retries, mtu, congestion control, etc.  Oh wait, you already did that.  Nevermind!

 

The managed implementation is especially worthwhile if you make a shield based this device, because then you can add it onto some existing platform.  It is a small wonder to me that shield vendors do not supply rich, robust, support software, but perhaps that's due to the dynamic of this DIY market.  Still, it seems a fertile ground for an enterprising person to produce a cc3000-based shield, supply excellent support software, and just beat the pants off all the current alternatives.  (well lasting until at least the next person makes a cc3000 board, and tells folks to download your free support software, haha, but that's part of how this market works.  then you have to differentiate a different way.)

 

I suspect that they won't change the firmware and hardware in a way that would break your implementation.  That would be bad business.  Maybe they would come out with a new device, shipping both, then obsolescing this one.  But its a moderately new part.

Ziggurat29, You have to let me help you.  I was just gearing up to do a .NET MF port myself.  I have an CC3000EM and I was about to setup an Arduino and ...

 

Sure, why not?

My plans (up to this point) were:

*  prove hardware interface (done)

*  prove SPI communications (done, I believe)

*  first make a managed code 'driver'

*  then make a native code integration with the firmware

So, two 'products' come out, one managed, and one native.  I want to do the managed version first because I believe it will be easier to experiment and debug in that context, and should cement my understanding of the part (the documentation is stunningly poor), and because I think it is a useful end in it's own right.  Once I have a thorough understanding of the device, then for the firmware it's a separate exercise to plan the integration, ostensibly replacing lwip (or maybe they can coexist, but I need to get into netmf's networking code to see what that means, since you'd effectively be making a multihomed system).

 

...  Can you post a zip of what you have so far?  Being able to start with (at least) the basic SPI stuff working would be very helpful.  

 

What I have right now, such as it is, is really exploratory code with no design to speak of, so it would be an embarrassment for me to post it.  If you really need it, I can douche out my more spirited comments and send it to you PM or something, but really I can sum it up this way:

 

Electrical:

using NP2

D13 - sck

D12 - miso

D11 - mosi

D6 - /IRQ

D5 - PWREN

D4 - /CS

3.3v  - pwr *

GND - no 'earth'ly idea

 

*  this will have to change soon as I start doing radio stuff; too much load

 

I am manually managing /CS and monitoring /IRQ for now -- maybe forever.  The SPI transactions often have to be done in two parts, and /IRQ is irksome in that it has mixed duty and doesn't seem useful to use it as an interrupt source, at least not so far, and anyway it gives me the feel of being level-sensitive and that's not supported on the NP2, but I'm not sure.

 

Software:

 

things:

SPI cc3000;   //I spi something that begins with the letter 'cc'    OutputPort cs;    //active low    OutputPort pwren;  //active high    //InterruptPort irq;  //interrupt; active low    InputPort irq;    //YYY I'm going to poll this for now until I understand this device better  

config:

  //make our spi (mode 1)      cc3000 = new SPI(new SPI.Configuration(        Pins.GPIO_NONE,    // SS-pin (we will manually do it)        false,        // SS-pin active state (low)        0,          // The setup time for the SS port YYY 50 uSec        0,          // The hold time for the SS port        false,        // The idle state of the clock (low)        false,        // The sampling clock edge (trailing)        1000,        // The SPI clock rate in KHz        SPI_Devices.SPI1));  // The used SPI bus (refers to a MOSI MISO and SCLK pinset)      //make our (manually controlled) cs (active low)      cs = new OutputPort(Pins.GPIO_PIN_D4, true);      //make our power control (active high)      pwren = new OutputPort(Pins.GPIO_PIN_D5, false);      //make our interrupt input (active low)  //XXX holding off on this until I understand the device better      //irq = new InterruptPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeLow);      irq = new InputPort(Pins.GPIO_PIN_D6, false, Port.ResistorMode.Disabled);  

  //power up      pwren.Write(true);  

 

the spi clock speed was chosen semi arbitrarily, to make debugging with the scope easier.  Side note:  specifying 1000 KHz actually gave me a clock of 640 KHz.  I measured.  Maybe a Gates reference joke -- 'who will ever need more than 640K'?  anyway....

 

action:

 

The SPI transactions are mostly normal.  'Mostly', because:

*  the first one only after powerup requires a 50usec pause after the 4th byte before continuing.  seems like a workaround for device bug.  I do this by two sequential WriteRead operations.  netmf is slow enough that you don't have to use any delay code, and you get about 84 us delay.  happily there doesn't appear to be a max delay.

*  the reads involve retrieving a length of the variably sized payload that follows, so you need to do those transactions in two phases also.

 

goofy first write (also this required to be a 'link start' command):

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()){}      begin();  //assert cs and (redundantly) wait for irq      //delay(50usec);      //goofy first write has a little pause after the first busy bit before moving on with the rest      cc3000.WriteRead(pktLinkStart, 0, 4, null, 0, 0, 0);      //delay(50usec);        //and then the rest of it      cc3000.WriteRead(pktLinkStart, 4, 6, null, 0, 0, 0);      end();  //negate cs  

reading is a little interesting in that you must retrieve the length, and then complete the reading:

 

  //wait for the signal that its ready      //XXX III support a timeout      while (irq.Read()) { }      begin();  //assert cs and (redundantly) wait for irq      //write header and read the length bytes      cc3000.WriteRead(pktReadHeader, 0, 5, pktReadPayloadLen, 0, 2, 3);      //make length into a number; header is big endian.  other things are little.      int nPayloadLen = ( pktReadPayloadLen[0] << 8 ) | pktReadPayloadLen[1];      if (0 != nPayloadLen)      {        byte[] pktBogoWrite = new byte[1];  //dummy        //read payload        //XXX sanity check on length        byte[] pktReadPayload = new byte[nPayloadLen];        cc3000.WriteRead(pktBogoWrite, 0, 1, pktReadPayload, 0, nPayloadLen, 0);        //XXX III 'spatchy      }      end();  //negate cs  

OK looks like I did wind up posting most of what I did so far, haha!

 

Some things:

 

*  a healthy level of distrust of the documentation is worthwhile.  For instance, they contradict themselves in what is the spi mode to use.  It is spi mode 1.

*  you can tell that different engineering teams worked on this, not necessarily in concert for whatever reason.  For instance, some values are big endian, and others are little endian, so watch for that.

*  the 5 byte header I would probably re-phrase as:

  *  unsigned char byDir;  //1 = write, 3 = read;  from the spi master perspective

  *  unsigned short sWriteLen;  //little-endian;  when op=1, master indicates payload length; otherwise zero

  *  unsigned short wReadLen;  //little-endian;  when op=3, slave indicates payload length; otherwise zero

 

I think this covers most of the SPI; I still need to get a handle on whether there is more /IRQ consideration since the doc claims it serves some double duty, and that there is collision resolution to be performed.

 

Beyond that, I planned to do some reading in the light of my newfound knowledge, before I do much more coding.  There's something called 'patches' which are not really clear to me if I care about, and they use the term 'event' which I think really means 'return value' and 'asynchronous notification'.

 

On the plus side, it looks like the part is what I would describe as:

*  SPI-based RPC mechanism to Berkeley sockets, with some added stuff as needed (e.g. setting mac, wifi keys, etc).

 

So I think it should be straightforward to implement an API even on the managed side that very closely resembles the existing network api, and possibly on the native side to mesh with what exists there as well.  Hope springs eternal!

I did try the dead chicken routine but nothing in particular happened (other than our old parrot arising from the dead which was kind of freaky btw).

 

I too have a Bus Pirate laying somewhere, still untouched since I use the scope instead, it works pretty ok for me.

 

Vdd is 3V3 but I might have accidentally applied 5V logic at some point effectively killing the pin (I'm using my own USB explorer board, not a Netduino).

 

Btw, are you also using the older TiWi-SL eval board from LS Research?

TiWi-SL.jpg

I soldered short wires onto pins 7 - 12 on both the J4 and J5 headers (and left all other pins unused), then stuck it down a regular breadboard.

 

well, at least you can have the chicken for dinner.  and zombie parrots are quite the thing I hear, but careful of the bite.

 

I did read that the boards are very un 5v friendly, so you may indeed be hosed.

 

Yes, that is the board I am using.  Didn't know there was a newer one, and digikey didn't have any advice, but it was kinda spendy anyway.

I probably should have taking your pin route (on the breadboard); I make a 'conventional' upward facing header that I could use the ever-popular-and-formerly-scorned-by-myself-but-now-I-am-a-convert jumper wires with female ends, so I could simply plug them into my NP2, but then I can't connect probes at the same time, so I had to solder additional free leads to probe with.  Would have been better your way on a breadboard!

 

Anyway, I'll give it just a couple more hours, then I have to go back to my regularly scheduled work for the rest of the week, alas...

Well, stop your grinnin' and drop your linen, it responded back to my kookily-crafted initial packet in a cogent way.  Now I will have to Shake a Leg, haha.

You can usually ignore those warnings, vendors typically stress such things on samples to maximize the probability of users achieving success in evaluating the part. I'm pretty sure you can leave the bag open for years and it will still work and yield an ok product for hobby purposes.

yes, moisture can absorb into the epoxy, potentially causing issues in reflow oven, so they recommend baking to drive it back out if it becomes 'moist' (i think physical distortion during the process, but I can't recall precisely).  important if you're wondering why your yields are lower than expected when making a zillion units, but if you're prototyping, you're probably more suspicious of your manual soldering; at least I always am haha.

your mention (hanzibal) of the .6 dip header reminded me of something:  The width of the cc3000 is such that the pins would be under the edges of the unit;  since the sparkcore photo shows the pins will to the side of the radio module, then I suspect that it is not a standard DIP footprint, that it is two rows of pin headers on a .7 or maybe even .8 width.

well I'll be back in town in a few days.  we'll see if any coding work is left for me to do....

we've got functioning dev boards and plenty of coding work to do.  Have fun on holiday (well, if it is holiday; 'good luck' if it's business)

Sweet Jesus!  That's great valkyrie; if you want, go ahead and put it on the codeplex; it probably would be messy to shuffle intermediate builds back and forth as forum attachments, and possibly confusing for someone who wants to download it.  I've not used the codeplex, but I imagine it is similar to all the other hosted scm, but with a dotnet focus.

I look forward to checking it out!

 

Hanzibal, I'd love to see your board layout when your ready to share (and if you're open to possibly annoying but respetful feedback).  Maybe even you could stick your eagles in a directory in the hypothetical hosted scm?

...

@ziggurat29: Have you ever considered politics or have they perhaps already got to you?    SMD.

politics?  never.  you got me beat this time on the reference joke, though!

 

But the ancient dusty frustum of a pyramid numbered 3^3 + 3 - 3/3 will give it a rest until the day of the moon....

Only comments I can add (for what they're worth) to Baxter's statement are:

*  LDO; low dropout from what input?  If it's a big enough difference, like 5 > 3.3., maybe ldo is not needed?  or maybe my bar for low is high? haha

*  it seems there are two potential hardware realizations:]

  1) a DIP form factor, with a premium on size/shape

  2) a shield form factor, with a premium on electrical compatibility (3.3/5v) (and also a form factor, but that's easy to achieve, but please do support the v3 pinout)

 

'2' speaks for itself, I think, and you'd probably be just fine using the Vin pin without needed a barrel connector.  Or if you really want to, use the Vin, and support an unpopulated barrel connector that can be selected via jumper or probably even solder bridge, because I suspect that the need for external versus using Vin is rare.

 

'1' maybe bears more discussion.  I do personally put a premium on the 0.6" spacing, and similarly on a 24/28/40 pin layout.  Also, I am not a mini user, so I'm naive to that market.  But...  Secret Labs' made a conscientious choice in designing the mini to be BASICStamp compatible (much as the netduinii are arduino compatible), ostensibly because this makes them more marketable by being able to leverage the existing community.  I think this has definitely worked with the 'duino' line -- can't say about mini because I'm unfamiliar.  Maybe what folks want more is 'small' rather than 'basicstamp compatible'.  In which case, I'd argue to make a 40-pin factor, with whatever pinout gives the strongest capability.

 

Lastly, out of respect for our host, Secret Labs is a hardware company.  They don't make anything off the software at all.  The software is free, and open (happily), and exists to support their hardware sales.  So, personally I feel a little awkward about discussing too much the notion of making alternative hardware in this forum, unless it's in the context of 'if you build this, we will come'.  Everything discussed up to this point has been completely open, but I mention this now really just to be explicit and clear.

The radio, when trying to set the pwr_en input pin high by applying 3.3V to it, it seems to result in a short circuit.

blick.  and how weird, because that pin is indeed a 3.3v digital input.  Maybe if you wave a dead chicken over it, and say a prayer, it will come back?  Occasionally incense helps, also.

 

Then maybe that's why mine won't speak back to me?  Now I must break out the oscope (and figure out a way to hook to my crazy modded pin header).  (now I wish I had a logic analyzer!)  (maybe this will finally make me use that bus pirate I got ages ago)

 

Unrelated, but I got a 'product obsolete' notice on this eval board (296-30564-ND), with no replacement suggestion.  Not the module itself mind you but the board.  Don't know what that means or if it is news you can use....

I think I just fried mine  Seems pwr_en is ground and it's supposed to be an input...

 

your radio or host board?  I've flicked pwr_en high and low just fine, so maybe double check the wiring, maybe it's OK!

 

OMG I am not sure if I have seen a more poorly documented device.  Does TI actually make this, or resell it?

 

Sounds like you guys with the TI eval boards are moving ahead with the 'stock' code to make it do something interesting.  I'm going to continue to plow through the hard and stony soil of non-docs in hopes of finding some rich volcanic earth beneath.  Or maybe only bedrock....

...
http://www.lsr.com/d...ts/330-0086.pdf

What do you need to know?...

 

hmm, could be usable for development at least.  won't win any 'sexy dev board of the month' contests, but hey its a dev board.

 

I was needing software info, but I found these two that should give me enough reading for today:

http://processors.wi...Interface_(SPI)
http://processors.wi...ogramming_Guide
 

at the outset it might be too much for a managed 'driver'.  well maybe.  maybe not!  I say this only because its' interrupt driven and I was concerned about latency, but then if it's handling the network stack, then it is also handling acks and retries so the host may be able to be more leisurely about servicing requests.

 

 

...Too bad there's no F4 in 48 pin package....

 

well the current mini uses a 64-pin package does it not?  anyway I know the various ghi boards in dip form factors do, so it should be doable from a layout perspective.

 

OK well hmm I may have to carve out some time this summer.  I am currently distracted trying to port an RTOS to the NP2, and ultimately port netmf on top of the RTOS, but that could take a while (if it even works out), and I may need a distraction from my distraction.  Plus, this wifi capability is germane to some paid work I'm doing, so maybe I can fold it in that way....

 

Thanks for the links!

 

-dave

ps hanzibal, I have been meaning to do your oscilloscope art, but I haven't been able to get to it yet, haha

ps baxter, I have always been envious of your avatar -- it reminds me of Lord Melchett from Blackadder, and consequently when I read your posts it is always in that character's voice, haha

that stm32 has 128k flash, and 20k ram, and apparently netmf needs 256/64 min:

http://en.wikipedia....Micro_Framework

pity that they couldn't have splurged another $3 for an F415 (well the package is bigger, but for a dev board why not have more power?)

 

Have to look at that wifi module though, a good bit cheaper than the roving networks ones...

OK, well it will probably a a couple weeks before I can fiddle with it.  Too bad centerblack doesn't have spares of his breakout board, I'd rather than than the gauche TI dev board, but I did order one.  Digikey thanks you, at least; haha.

well, if the goal is 'use the spark core' then you probably are out-of-luck for netmf directly, as you point out.  but if the goal is 'make a new hardware', then it should be easier, because you can put in a better processor.  the package of the 415 is 64 pin, and spark core's is 48, so you might have some placement challenges, but I think the mini is already using a 64 pin device, so it should be doable.

 

if you talk to it through a uart, that kinda loses the benefit of spi, right?  I haven't looked at the datasheet, but now I'm curious about the difficulty you mention.  From the outside, it looked like it presented a high-level interface to networking; i.e. it has its own tcp/ip stack, and works similar to how many of the shields work.  In a way this might make integraiton easier.  Well let me rephrase that; it would make integration easier except for the fact that lwip/enc38j60 is already integrated, and what can be easier that work already done?  So it requires positive, non-zero, effort, but probably would reduce the code footprint a bunch.

 

Hmm.  now I'm curious.  I wonder if someone has a cc3000 on a breakout board....  I don't know how digikey is selling them for 12.50 when others (e.g. mouser) are selling them for about double that.  Maybe they have a special deal with ti...

let us know how it goes; I could have had 2.5 for the price of 1 relative to the behemoth TI board I got!  Maybe I should get a couple myself....

EDIT:  my eval board arrived, so maybe 3-4 days from now I can carve out some time to at least solder on some pin headers and try out the SPI a little.

EDIT2:  well, the existing holes for headers are not on .1" pitch for common snappable headers; blick.  well, I suppose I can jury-rig something, I only need 8 points, I think...

well I soldered on some pin headers ('custom made' since they are on an unusual 2mm pitch).  we'll see if I can get something to go over the spi; maybe there's a 'version' command or something similar....

Good eye, Dave. Good eye. That shouldn't have any adverse effect, but we'll be sure to check it into the next revision.
Thanks for helping us all get GCC up and running.

Yeah it looked minor.
Well, no need to break out any champange yet on the gcc build:

region `LR_FLASH' overflowed by 164760 bytes

and I guess I have to make a scatterfile for the tinybooter from scratch, since it wasn't in the source bundle. Do I really need to make a tinybooter? Can I not just keep the existing (production) one on the flash? I'm eager to smoketest a binary built from this toolchain.

-dave

yay, jtag pods and micro 10pin adapters and pin headers and soldering has happened.  and I downloaded, installed, configured, and ran OpenOCD and can connect to it.  Because I don't know gdb natively, I also installed Eclipse, the CDT, and am configuring that.  There is no 'elf' output file from the build (that I can see), so I have to think about that some more....

Edit:  looks like the AXF file is in fact, an elf file.  cuz we need more filename extensions, I suppose.  Anyway, at length I have debugged past the boot loader, into the tinyclr, and fairly early in the process it goes off the rails with an illegal instruction. At present it looks like the PrepareImageRegions is where the fault is stimulated, so I need to look at that some more...

Edit2:  I discovered that the stack was smashed during Prepare_Zero; I disassembled the stock firmware for comparison and discovered some erroneous constants stemming from scatterfile errors.  I corrected those and got past that crash, but have happened upon another one in HAL_Initialize(), so the process continues.  This time it seems to happen at ENABLE_INTERRUPTS(), and interestingly doesn't happen when I single-step, only when I 'continue' through it, so maybe some interrupt aspect is wrong...

Edit3:  I discovered a couple more scatterfile problems involving placement of the interrupt vectors and the 'custom heap', I am still trapping, however I notice a curiosity:  In the disassembled firmware, the vector addresses are odd, and in the built firmware, they are even.  Looking in the armarm (for v7m) I see that the low bit MUST be set, so I am really curious as to why this is not being done for the gcc build; almost like an arm/thumb problem.

Edit4:  Well, I got it to the point that I can connect with the MF Deployment tool, and ping, and get Device Capabilities, so it's getting there.  However PlugIn Debug Show Device Info faults, so still more work to do.  I also wish there was a comprehensive test app so that I can get some code coverage, to weed out any other faults.  I'm still distressed about the item described in Edit3, which I worked-around in the interim by explicitly setting the low bit, but I'm sure that's not the 'correct' fix.

Good news indeed; glad it's working for you!

 

sure; re: jtag.  I didn't do anything terribly complicated, but here is all of it FWIW:

*  I installed a prebuilt openocd-0.6.1 version.  Maybe I got it from sourceforge?  The file I downloaded was openocd-0.6.1.zip.  I installed to:

  C:openocd-0.6.1

*  Happily, I didn't do anything fancy with the configuration.  I just made some config scripts I found handy.

• in 'C:openocd-0.6.1scriptsboard' I created 'netduinoplus2.cfg'.  This was simply a copy from 'stm32f4discovery.cfg' and I didnt' edit anythng, but I made a separate file nonetheless in case I did need to edit something (but I never did).
  

  # This is for the Netduino Plus 2, which I simply copied from stm32f4discovery.cfg# This is an STM32F4 discovery board with a single STM32F407VGT6 chip.# http://www.st.com/internet/evalboard/product/252419.jspsource [find interface/stlink-v2.cfg]source [find target/stm32f4x_stlink.cfg]# use hardware reset, connect under resetreset_config srst_only srst_nogate

   

• Then, in the 'root' of my project directory (which happens to be 'C:Experimentsnetduinonetduino_plus_2', I created a batch to start up openocd, which I named 'startOpenOCD.bat':
  

  title OpenOCD to netduinoplus2C:openocd-0.6.1bin-x64openocd-x64-0.6.1.exe -f board/netduinoplus2.cfg

• Then, in that same 'root' directory, I create a batch to startup gdb, called 'startGDB.bat':
  

  title gdb for arm tinyclrarm-none-eabi-gdb.exe -x gdbinit.txt C:Experimentsnetduinonetduino_plus_2BuildOutputTHUMB2GCC4.6leFLASHreleaseNetduinoPlus2bintinyclr.axf

  the interesting thing that took me a while to understand is that the *.axf (ARM eXecutable Format) file is actually just an ELF file with DWARF info, so gdb can take it as-is.
   

• That batch uses a startup command file, called 'gdbinit.txt':
   

  set remote hardware-breakpoint-limit 6set remote hardware-watchpoint-limit 4target extended-remote localhost:3333monitor reset halt

  which gives gdb some useful advice, and also tells it to reset the board like it just powered up.

So, to do debugging, I did this hardware action:

• I plugged in my STLinkv2 to the computer
• then I connected the STLink to the adapter board
• then I connected the 10 pin micro idc to the Netduino Plus 2
• then I connected the netduino plus 2 to the computer via usb.  Or powered it from power supply, whichever.

Then this software action:

• start 'startOpenOCD.bat'.  If it immediately exits, that means it couldn't talk to the stlinkv2.  Re-check all that; maybe repeating the hardware connect sequence.  When it does work, you should see a 'dos box' window running the openocd monitor, and it should be 'quiescent', i.e. no incremental output, especially no continuous output indicating that it is trying to connect.  If that happens, shut it all down and restart the process of connecting the hardware and starting the software.  It will work!  Just not always, alas.
• Then start 'startGDB.bat'  This will open an interactive gdb prompt, and is where the work will be done.  Ostensibly, if you get Eclipse working, then you wouldn't do this because eclipse would be driving.  But I did it manually.  The command script I gave will be executed, and it will do a hard reset of the board and put it in a halt state, so you can start single stepping the boot process.
• The first part is in TinyBooter.  You don't have the proper source for that since we told gdb about tinyclr.  Take it as read that TinyBooter works, and whiz through to the start of TinyClr, with this:
  • tbreak *0x08020000
  • cont
• You'll whiz through and stop at the very start of your built firmware.  Symbol names (for functions) will be meaningful now, so you can use them for your breakpoints instead of addresses.
• It's a little slice of Hell to use gdb from the command line, but I found 'tbreak' 'disassem' 'info registers' and 'si' and 'ni' and 'finish' to be oft-used.  Occaisionally 'bt' but you have to take the output  with a grain of salt.  If you're a noob as I am, then get the GDB Quick Reference pdf off the web.  If you can get Eclipse configured to step through the firmware, then you win the Magic Cookie.  I had to stop messing with Eclipse early on because I didn't know if I had my ocd straight, and by the time I did, I had mostly solved my problems, so I never got back to the Eclipse config.  But if I had to debug again, I'd give my kingdom for an gui interactive source level debugger.

Also, I found the STLinkV2 to be quite twitchy, and prone to giving up the ghost easily.  Or maybe you can blame OCD, but many times Id find my gdb non-functioning, and see in the openocd window that it had gone into some 'lost connection, reconnecting' cycle.  When that happens, you have to shut down the software, unplug the USBs, and go through the hardware reconnect and software bringup again.  Yay!  I like wasting time!  Separate note, this seems to happen for me anytime USB re-enumerates.  I.e., if the board reboots and goes through the USB enumeration procedure, it tends to hose my STLink connection.  E.g., if I am debugging via jtag while I am also connected via visual studio and deploying software (which will cause the board to restart).  This rather puts a damper on debugging into that stuff effectively, alas....

 

-dave

The Netduino Plus 2 firmware is based off of .NET MF 4.2 QFE1 so be sure to copy it over the 4.2 QFE1 PK (instead of 4.2 QFE2).

Yes, haha, at length I did figure out that. Now it seems I am down to 'scatterfile' problems, so I'll need to figure out how those work. They seem to be some sort of memory map definition for the resultant image.

I did find what seems to be a genuine bug;
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_PWM\STM32_pwm_functions.cpp:284
I'm pretty sure that should be a == (comparison) instead of an = (assignment). And also a lesser quasi-bug:
* C:\Experiments\netduino\netduino_plus_2\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_USB\STM32_usb_functions.cpp:417
for my setup, __packed is not defined, and I resolved this by adding

#if defined(__GNUC__)
#define __packed    __attribute__ 
((__packed__))
#endif

before that line. I say this is a quasi-bug because I somehow feel unclean about my 'fix', that there is a better place for that definition, and that maybe it should have been picked up.

Oh well, it's compiling now, which was a feat, so on to scatterflies for the moment.

-dave

Success!  I have built the 4.2.1.2 firmware with the yagarto gcc 4.6, did things with the MFDeploy, and have made a blinky and deployed and stepped through the app with the debugger in VS2010.  I do wish there was a comprehensive (even if only slightly so) 'unit test' app to validate the build, but I'm going to call it macaroni for now.

 

Shoutout to Valkyrie-MT for advice and also reference to another gcc-derived tool chain that may be more well-behaved than the yag, and especially to CW2 for giving me the final incantation needed to make the linker not do army things for thumbs when linking assembler objects.

 

Its odd.  I have never been so pleased to labor so hard to acquire what I already had to start with.