Sudden Impact Challenge - Blog Entry 4

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.

Sudden Impact Challenge - Blog Entry 3

The past week has been spent trying to get a reliable SPI connection between the MSP430F5529 and the Analog Devices sensors as well as mapping pin connections for all devices needed for this project.

SPI Connection

The initial design plan was to use one SPI module for all SPI devices, this would include the CC3100 as well as the accelerometers and temperature sensor. The spi.c file was altered to allow for multiple device selects and all code was changed through the tcp_socket demo project. Once this was cleaned up and compiling with no issues the code was tested with the CC3100 and found to be working reliably. The next step was to attach a second SPI device.

At this point interesting things started to happen. When the ADXL362 was connected as it should be (MISO <->MISO, MOSI<->MOSI…) the CC3100 no longer worked, however, switching the connections (MISO <->MOSI, MOSI<->MISO) the CC3100 proceeded to work again. Using a logic analyzer it was clear the SPI was communicating in both cases but possibly not correctly (clock ticks were missed due to sampling rates of the old Saleae Logic) . It was also pretty clear from the sample data that the SPI frequency was set to 12 MHz. Once this was discovered and realizing it was not a hardware issue (verified using a Bus Pirate to talk to the ADXL362) the datasheet for the ADXL revealed the clock speed for the device MUST be between 1 MHz and 5 MHz (or 8 MHz depending on datasheet version). The Plan now is to write a new SPI driver for the ADI devices that will run at an acceptable clock rate for ALL the needed devices (ADXL362 1MHz - 5MHz, ADXL375 < 5 MHz, ADT3720 - Unknown). Once reliable communication has been established correct interpretation of input data will be worked out to enable proper interpretation and use of sensor data.

UART Code Removal

Also this week, time was spent removing code to control the CC3100 via UART. This was done to increase code readability and to remove possible confusion within the code. This was also done to help identify unused pins that may be used for the UART control of the CC3100. During this process the overall understanding of the code was greatly increased.

Pin Mapping

Since there was no clear indication of what pins were free, a quick code review was done to find all used pins and what they were used for. This was done to find all available pins and to correctly detail the used pins. As can be seen in the table below the CC3100 has a lot of pins broken out but only six are used. There are four for SPI, one for interrupts and one to enable and disable the CC3100, this excludes the 3.3 V rail and ground.

Once these were eliminated from the list six analog pins were selected, these would be set aside for the ADXL377 and time permitting the heart rate monitor. These were chosen next as there are only a limited number of analog pins on the MSP430F5529 and it was preferable to try have them consecutively numbered to potentially allow for easier programing.

Once the analog pins were selected the SPI for the ADI devices and their chip selects were chosen. All pins assigned so far can be seen in the table below.

Table 1. Pin Mapping For MSP430F5529 & CC3100

Next Steps

This coming week will be spent getting all SPI devices working correctly and reporting back some data (Device ID) and formatting that data correctly. Once the SPI modules are working correctly and their data is correctly interpreted the ADC module will be attempted.

It may be obvious by now, but the user interface has been neglected at this point due to complexity in the learning curve for QT. For now data will either be sent to plot.ly for plotting at a decimated rate or logged on a local computer in a not athsetic interfcae, something like a terminal.