The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I'm in the process of migrating my project over to the Plus 2 from a Netduino/mini. I've been able to get three of four spi devices working. Two devices worked straight away, and one needed some pauses added in the driver, presumably due to the faster chip. The fourth spi device is resisting all attempts to get it up and going. I've tried:
NetduinoPlus2_Firmware_4.2.2.2.dfu and NetduinoPlus2_Firmware_4.2.2.1.dfu,
speeds ranging from 1250 to 10000 KHz,
all combinations of idle state and sampling clock edge,
adding various setup and hold time pauses,
adding pauses to the driver.
The device is a pressure sensor that senses both pressure and temperature. With one parameter set I can see temperature being measured correctly about every third or fourth restart of the program, but pressure is never reported correctly. I don't have a scope. I would buy one if I thought it would get me through this. Other options are re-do two pcb's and try and get the pressure sensor up with I2C (my Plus 2 is a home brewed "mini 2") or give 4.3 beta a shot after biting the Windows 8/VS2012 bullet (right now running XP and VS2010; I have things I have to maintain under 4.1). Any thoughts/suggestions appreciated.
I made some progress getting the 4th spi part to work on the move from 4.1 to 4.2/4.3. I was using an analog pin as chip select. When I used one of the other digital pins that helped somewhat -- the pressure sensor works immediately after a reset signal is sent... *most of the time*. This is strange behavior. Normally the reset is sent to the pressure sensor once upon power up, and then the pressure is read thereafter without any further need for resets (actually it's a reset and then read of coefficients for later pressure calcs). The kludge of reset/pressure read would be okay... However, the inconsistency where pressure is not read correctly say 10% of the time is not. I can see I would benefit from a scope. However, I won't go down that path unless the move to I2C doesn't pan out.
After more fiddling I have the spi pressure sensor functioning with workarounds. I made "init/coefficient load/pressure read" a combined method for every pressure sensor read, instead of "init/coefficient load" once upon power on, and then only "pressure read" subsequently, as with the program under 4.1 and based on the way the part is supposed to function. The "init/coefficient load" somehow stabilizes the "pressure read." Also, on power up I have to run "init/coefficient load/pressure read" three times before the pressure reading is made correctly. Due to some strange spi instability, the first two reads are always garbage. After the first two it's fine. I just implemented a counter to ignore the first two reads. So, my dive computer is now (more or less) moved from 4.1 over to 4.2/4.3. Phew...
Hi cys,
Are you using "clock idle low" and "trailing edge" settings for your SPI device by any chance?
There is one known SPI bug in the 4.2.2.2 firmware. We're addressing it with the 4.3 RTM firmware.
http://forums.netdui...0327-spi-issue/
If you have different settings, we'd love to find a way to dig into them. We want code to be as backwards compatible as possible between gen2 and gen1 boards.
Chris
static SPI.Configuration Device1 = new SPI.Configuration( Pins.GPIO_PIN_D6, // SS-pin false, // SS-pin active state 0, // The setup time for the SS port 0, // The hold time for the SS port true, // The idle state of the clock true, // The sampling clock edge 4000, // The SPI clock rate in KHz SPI.SPI_module.SPI1 // The used SPI bus (refers to a MOSI MISO and SCLK pinset) );
So, I guess I should think about purchasing a scope.
Below is what I see with a logic analyzer. There are 13 transactions with the pressure sensor for each pressure reading. Attached is what the first 3 transactions look like from the first 4 pressure readings. Stable pressure readings are seen in my program beginning with the 3rd pressure reading, consistent with the logic analyzer data. (I have not yet done the logic analysis to try and figure out why I need to reset/read coefficients each time I want to read pressure, as opposed to reset/read coefficients once on program initialization).
After untangling some things further, I have found that if I place the "init/coefficient read" of the pressure sensor at the end of my surface subroutine, the sensor is initialized correctly and the coefficients are also read correctly, and they remain stable through further pressure readings. Under firmware 4.1 the pressure sensor "init/coefficient read" occurred near the start of the program, and functioned flawlessly. Under firmware 4.2 corrupt data resulted with this aforementioned placement, along with placement in the beginning or middle of the surface mode subroutine, a little further into the program. Only when the "init/coefficient read" is placed at the end of the surface subroutine is it successful. Strange.
Hi cys,
Hmm, very interesting. If you have access to a logic analyzer and can capture what's happening on the wire, we can take a look at your project code and hopefully help explain why this works when you move code around.
We triple-checked all four SPI modes with the latest 4.3.1 firmware. It's conceivable that there is an edge case bug or that STM32 SPI timings are slightly different than the Atmel SAM7X timings were (or that the target chip works better at a specific SPI clock speed). But from a SPI protocol perspective, in all of our logic analyzer traces, the STM32 chip appears to be reading/writing data properly on the wire in all modes with the 4.3.1 firmware.
Chris
The logic analysis attached as a pdf in post #9 in this thread shows what is happening on the wire using firmware 4.2. Actually I didn't rearrange the code. The logic analysis showed the first two readings from the sensor (different lines in the program) are corrupt but later readings (later lines in the code) are correct. Strangely, what I found was if I put a counter in place that omits the first two readings after program start only (the first program loop), all later sensor readings after the first program loop are correct (even the first two that were corrupt in the first program loop). In the pdf -- logic traces labeled 1st time and 2nd time are the first two readings after the program starts (corrupt), and logic traces labeled 3rd time are 4th time are the next two readings in the first loop (not corrupt). I can do the logic analysis for firmware 4.3, but right now the behavior looks the same as what I saw with 4.2.
On reflection, it may well be that the power consumption of the STM32 is affecting the stability of the sensor briefly at startup, as looking at the logic traces it seems the sensor output is the issue. I will try adding a brief pause at program start to let things settle/stabilize and see if that fixes it.
static SPI.Configuration Device1 = new SPI.Configuration(
Pins.GPIO_PIN_D6,
false, // CS active low
0, // CS setup time (2us)
0, // CS hold time (2us)
true, // clock state during idle
true, // sample of which edge
4000, // clock rate in kHz
SPI_Devices.SPI1);
In your sample it looks like you are using the Microsoft SPI class, however in the sample above I'm using the Netduino class. Let me know if that works or what changes, if any, you find with your LA? I did notice some unexpected blips with the MS SPI class on the MISO line, however the Netduino class looks pretty clean. Also I'm not sure if this is an issue or not, but I generally prefer to initialize any static objects within the Main class to ensure everything is initialized in proper order.
I changed over to the Netduino spi class, but it didn't fix the issue. Also, all static objects are initialized in the Main class. Thanks much for the suggestions.
I tried adding a long pause before the sensor is read for the first time to see if sensor stability was an issue, and there was no change.
In general, the program has been working for several years under 4.1 without issue. I've done a matrix of timing changes for the sensor when moving over to 4.2/4.3, both in terms of bus speed and between program arguments in the driver. I guess I'm happy with my strange workaround for now. If anyone has any more suggestions of things to try, I'll give those a shot.
Hi cys,
I just pulled up the PDF file...
From the logic analyzer capture you did, it appears that the data is being sent properly--but the device is not responding properly--correct?
This may be a case of living on the edge of maximum power consumption or something that's specific to running your hardware in conjunction with the gen2 hardware (which requires a bit more power for the faster MCU).
To clarify: if you wait a little while before querying the device, the device responds correctly?
Chris
From the logic analyzer capture you did, it appears that the data is being sent properly--but the device is not responding properly--correct?
Yes and no. In first two logic analyzer captures the device does not respond correctly (labeled 1st time and 2nd time in the pdf), but in the second two captures the device does respond correctly (labeled 3rd time and 4th time). As an addendum, I would add that all readings after the second reading are correct (but none are shown in the pdf after the 4th reading).
To clarify: if you wait a little while before querying the device, the device responds correctly?
No, waiting before querying the device does not lead to a correct response. I tried adding a thread sleep of 5 seconds before querying the device and the response was still corrupt.
What is happening is the first two responses from the device are corrupt -- no matter how long of a pause is used before querying the device -- but all later responses are correct. My workaround is to toss the results from the first two device responses, as the device works flawlessly afterwards. Therefore, in a bizarre twist, when the program loops around and hits the two spots at program entry where the corrupt readings occurred initially, the readings are correct (the surface mode of this dive program loops continuously, with three separate command lines where the device is queried interspersed with other code).
I'm not impeded from using the program at the moment. I do eventually want to figure out what is going on. I've spent a lot of time troubleshooting it already, playing with program structure, etc. The workaround is the result of that effort so far.
I have to again note that I'm using the Netduino Plus 2 firmware with the home brew stm32mini.
