This branch contains test firmware for validating the functionality of an accelerometer board.
Right now, the testing is manual and requires looking at the printf'd output. I've been using the SWV console to see these within CubeIDE, rather than sending them to the usual UART via the STLink.
To get started: Project -> Build Project
Run -> Debug; then hit the green arrow/"play" button (CubeIDE calls it "Resume").
Window -> Show View -> SWV -> SWV ITM Data Console
If everything is working well, you'll see some output during initialization, then the average of 5 acceleration measurements:
#### Testing ADXL ####
Product revision ID: 1
Set range! 129
Read range! 129
Device set to 2G range!
Set output data rate! 3
Read data rate/filter! 3
Device set to 500.000 Hz!
Initialized measurement mode.
X accel = 0.668624 g
Y accel = 0.069473 g
Z accel = -0.749665 g
If it's not connected at all, it will fail from the start:
#### Testing ADXL ####
Received incorrect device ID: expected 173, got 0
** ADXL failed to initialize.**
The test firmware write data to the memory then reads it back. If it succeeds, it'll look like:
#### Testing external memory ####
... Set octospi1_stack[0] = 8
... Read back: 8
And here's an example of a failure when the chip wasn't plugged in to my breadboard:
#### Testing external memory ####
... Set octospi1_stack[0] = 8
... Read back: 136
I've been testing by shorting the Tx/Rx lines and writing a bytes at a time. I'm not sure of a better way to test this without adding an external dependency.
The read function will happily report that it received '0' if the wires aren't connected properly. So, confirm that the byte it received is incrementing.
Good:
#### Testing UART ####
... Testing UART! loop count = 0
... UART Received: 0
... Testing UART! loop count = 1
... UART Received: 1
... Testing UART! loop count = 2
... UART Received: 2
Bad:
#### Testing UART ####
... Testing UART! loop count = 0
... UART Received:
... Testing UART! loop count = 1
... UART Received:
... Testing UART! loop count = 2
... UART Received:
If the SD Card isn't plugged in at all, the first line in the console will say:
** SD FAILED TO INITIALIZE **
And then, in the SD section, you'll see:
#### Testing SD card ####
... Opening media.
** SD FAILED TO INITIALIZE **
If everything's working well, it should say:
#### Testing SD card ####
... Opening media.
... Creating file ext_board_test_0001.txt
... File already created!
... Opening file.
... seeking to end of file.
... Closing file.
... Flushing media.
SD Card test passed
You should then check that there was a file created / line written to the SD card
We have 4 GPIO pins mapped; one is polled, and 3 are interrupts.
The one that's polled will be implicitly tested by the ADXL check above (well, we assume data is ready if it's high). I'm not sure how you'd be able to test it in isolation, so maybe hook up an oscilloscope or logic analyzer and confirm that it toggles as expected rather than being pegged high.
After the rest of the tests are finished, create a rising edge on the GPIO pins to test that an interrupt is generated on: EXT_GPIO / ADXL355_INT1 / ADXL355_INT2
If everything is good, you should see:
Detected (rising) interrupt on ADXL355_INT1!