This past week or so has produced some promising movement as well as some valuable learning experiences, I will outline these below.
ADXL362 Dead
As noted in Blog Entry 3, I have been working to get the SPI working in a useful and simple format. While working on this there were issues in determining if it was the code or the ADXL362 that was not working correctly. This is where the first lesson was learned, the true value of simple and cheap test equipment. By simply connecting the breakout board to a Bus Pirate ($30) it was a simple matter to determine that it was the breakout board (I assume the ADXL362 itself and not one of the caps) was no longer working. This simple test board paid for itself just in removing aggravation and showing where the issue truly lay.
While I thankfully I have another breakout board from a previous project I am still unsure as to why this breakout board has stopped working. The connections between a previous test and the test that appeared to break the board where the same. In fact the board had been working over night and only the next morning did the board give up the ghost. Maybe after the challenge is over I will see about determining the real issue and possibly replacing the ADXL362 on the board.
Getting SPI Working
This leads to the second valuable lesson, the true value of demo code. While the CC3100 uses the SPI module and works well and the datasheet for the MSP430F5529 is pretty well written there were still issue getting the SPI working correctly for the ADI devices. TI has demo code for all the modules on the MSP430F5529 which gives a good starting point to get your code up and running. Again, here the Bus Pirate came in handy, the ADXL362 registers were returning values that differed from the datasheet, particularly the REVID, XDATA and STATUS. This was lead be to be a bit uncertain with the code I had written. I therefore again used the Bus Pirate to verify the correctness of these values. It should be noted that for all of the SPI testing the Saleae Logic was used to read the values sent and received to the ADXL362. Although there is now a new version I have found this to be an indispensable piece of test equipment that now together with the Bus Pirate has saved many hours of debugging.
Another interesting lesson learned was time delays in the SPI protocol or at least with the ADXL362. During some debugging there appeared to be an issue that I thought a longer delay could resolve or at least shed some light on so the delay between sending and receiving data was increased to ~100 clock cycles (for i < 100). Once this was done the ADXL362 stopped responding. Using the Saleae Logic analyzer it was easy to see that the only difference was the timing, while no information could be seen ADXL362 datasheet and in theory the time between sending bytes to the device is not constrained the long durations (1.17 ms vs. 0.56 ms) was not liked by the ADXL362.
SPI Logic
The last issue encountered with the SPI module was using an inbuilt delay between sending or receiving multiple data bytes. Working from the CC3100 demo the code implemented was as follows
while (!(UCA0IFG & UCTXIFG)); // USCI_A0 TX buffer ready?
UCA0TXBUF = 0xFF; // Transmit first character
while (UCB0IFG & UCRXIFG); ← Logically useless….
RxData[j] = UCA0RXBUF;
Logically this does not make sense, according the the datasheet URXIFG = 0 when no interrupt pending, therefore in the above case as long as an interrupt is pending the code should remain in the while loop and NOT service the RXBUF. What should work but doesn't for some unknown reason is ”while (!(UCB0IFG & UCRXIFG));”. With this logic the program reads the RXBUF only once and then appears to freeze without spending too much time on it I was not able to find a root cause for this. I would assume that somehow when UCTXIFG is read and therefore cleared UCRXIFG is also being cleared.
While this appears to work for the CC3100 I can only assume that the time RXIFG never gets set in this case possibly because the RX happens at the same time as the TX. I have not checked the errata for the MSP430F5529 but will possibly do so at a later date.
Note: It just occured to me that the code actually reads UCB0IFG which includes BOTH UCTXIFG and UCRXIFG thereby clearing both of them. While I a not sure if this is correct appears somewhat plausible. The only issue is that the same code still works for the CC3100 with no apparent issues, but that may have something to do with timing and that the CS pin goes high between a Tx and RX in that case.
ADC
Work on the ADC has also begun this week. While the sample code does yield some results it has so far proven unreliable but a starting point nonetheless. For further testing to again check the response as well as to get a better understanding of the ADXL377 (high g analog accelerometer) was connected to an oscilloscope to check responses and behaviour of the device. As of yet there appears to be an issue hopefully with the oscilloscope as the understood response should be ~1.5 V at 0g - 1g which is not was displayed on the oscilloscope. The oscilloscope used has been showing some issues (NOT the oscilloscope provided with the SIC kit but one at work) so hopefully when I can make some space on my desk I will breakout the new oscilloscope and test the part with that.Hopefully with the new oscilloscope a clearer understanding of how the ADXL377 works will be achieved as well as how to better interpret its output.
Next Steps
The next major step is to get the ADC on the MSP430f5529 working so that all three channels of the ADXL377 can be read and possibly the three channels of the AD8232 (Heart Rate Monitor Front End) working as well. Once this has been completed and well tested both the SPI code and the ADC code will be integrated into the overall project code and tested to ensure no functionality in the project code has been lost or corrupted.
No comments:
Post a Comment