This document captures common errors that may be encountered while using/modifying the Avnet RASynBaord Out-of-Box (OOB) application
- Hardware Issues
- Application Issues
- NDP120 Issues
- Debug Issues
- Development Issues
- Renesas Flash Programmer Errors
This entry captures two issues.
- If powering the RASynBoard EVK from just a LiPo battery the OOB application does not startup
- After powering up the EVK with a USB-C cable and a LiPo battery, after removing the USB-C power source the RGB LED on the I/O board is not operational
Note: You can power just the core board (the smaller of the two boards) with a LiPo battery, the application boots normally and there are not any other known issues. To flash your model files and configuration to the SPI Flash on the core board, see . . .
- For non-cloud connected applications: Application User Guide
- For cloud connected applications: RASynPuckDemo.md document to find detailed instructions.
- When powering the EVK (I/O board + core board) using a LiPo battery connected to the application does not boot.
- No debug is output from either debug source
- The RGB LED on the I/O board is non-functional
- Usually this LED lights on power-up while the application loads the NDP120 images
- Usually this LED lights whenever a feature is detected by the Syntiant NDP120
Unfortunately this is a hardware issue. Until this issue is resolved, the EVK can be run on a LiPo battery by following these simple steps:
- Power the RASynBoard EVK from either USB-C connectors
- Plug in the LiPo battery to the battery connector on the core board
- After the application has started, remove the USB-C cable
The application will run as expected with the exception of the RGB LED, that will not work when the EVK is powered by the LiPo battery.
We've identified a hardware modification that will resolve this issue. The only downside is that there is about a 1mW of additional current pulled from the LiPo battery with the modification.
There are two hardware changes required to boot and run the EVK (I/O board + core board) from a LiPo battery. The modification will permanently disable the U1 buck regulator on the I/O board and instead bridge the 3.3V_MCU and 3.3V_MCU_1 power rails. These changes can be made to the top side of the I/O board.
-
Disable U1 by desoldering the L1 inductor from the I/O board (L1 is much easier to remove than the tiny R13, R16 resistors) Functionally U1 is now disabled. External 3.3V voltage applied across it’s internal FETs should not be a problem. The risk of energy getting stored-in and discharged-from this L1 inductor when external 3.3V is applied, is also eliminated.
-
Add a short wire-mod between:
- Pmod connector J11 pin 13 (3v3_MCU) and
- Debug MCU header J3 pin 4 (3V3_MCU_1)
Notes:
- This will keep the I/O Board RX231 MCU and RGB LED powered from 3v3_MCU when USB power is not present.
- With the RUN jumper across J3 pins 1 and 2, the RX231 is kept in reset state, so current consumed by this MCU should be very low
This error has been identified to be an issue between the OOB FSP microSD card driver and a microSD card that may have errors
- The OOB application stops running, or does not perform some features
- The user button (button closest to the corner of the board) does not respond when pressed
- The issue is not reproducible when powering the board from the USB-C connector on the I/O board (the larger bottom board)
- Is only reproducible when powering the EVK using the USB-C connector on the core board (the smaller board)
To resolve the issue, fix any errors with the microSD card's file system by reformatting the card
- Copy all the files from the microSD card to a temporary folder on your development PC
- Format the drive as a FAT32 device
- Move the saved files back onto the microSD card
- Insert the microSD card back into the RASynBoard's I/O board
- Verify that the issue is not reproducible
- The ML model does not load
- You see debug similar to
This error occurred because the *.synpkg filenames defined in the selected config.ini [Function_x] block are not found in the root directory of the microSD card.
- Use the debug output to verify that the filenames defined in the selected config.ini [Function_x] block are spelled correctly
- Verify that the files specified in the selected config.ini [Function_x] block exist on the microSD card in the root directory
- The RGB LED lights and does not turn off
- The debug terminal is flooded with "NDP MATCH!!" messages
The following debug was a result of loading V1.4.0 models while running the V1.5.0 Out-of-Box application
The OOB application is built using a specific Syntiant SDK version. Any ML models loaded to the NDP120 must have been generated using the same Syntiant SDK version.
| OOB Application Version | Syntiant SDK Version |
|---|---|
| v1.1.0 | v100 |
| v1.2.0 | v100 |
| v1.3.0 | v100 |
| v1.4.0 | v103 |
| v1.5.0 | v105 |
| Release Date | Syntiant SDK Version used to generate ML models | Compatible Out-of-Box Release |
|---|---|---|
| Oct 2022 | v103 | V1.4.0 |
| Feb x 2023 | v105 | V1.5.0 |
- If using the pre-built ML models that come with the OOB application verify that you're using the microSD card files that correspond with the OOB application version. Each release is delivered with compatible ML models and the matching config.ini file.
- If you're building the application from source, verify that your microSD card contains the files from the ndp120/synpkg_files/ directory.
- If using models generated by Edge Impulse, refer to the table above to identify a compatible Out-of-Box release that supports the models generated by Edge Impulse.
If the application is configured to send debug output to the PMOD UART config.ini:[Debug Print]-->Port=1 but you never see any debug from that UART, or maybe you only see one print statement FreeRTOS ndp_thread running
- Verify that the config.ini file is correctly configured
- Verify that the microSD card is inserted into the RASynBoard I/O board
- Verify that the microSD card contains the config.ini file
When the microSD card is not inserted or if the config.ini file is not found on the microSD card, the application defaults to sending debug out the Virtual COM port associated with the USB-C connector on the core board
-
Check to see if the debug is being output to the Virtual COM port associated with the USB-C connector on the core board
- Initiate a NDP match to see debug
When using the Virtual COM port associated with the USB-C connector on the core board I don't see startup debug
This is an implementation artifact. Since this COM port is implemented in software, the application must bring the hardware interface up at boot time. This action takes longer than the initial NDP120 load/boot time.
There is an undocumented feature where the user can enter log in the terminal to dump the early debug after the fact. There's lots of room for improvement on this feature; however it works.
This section captures issues you may encounter when developing custom applications for the RASynBaord. The content here is specific to the Avnet RASynBoard OOB application, but should apply to other projects developed in the Renesas e^2 studio
When trying to debug the application (clicking on the small green bug icon in e^2 studio) the following dialog is displayed . . .
- Verify the debugger configuration
- Documentation Link - Setting up the debugger
- Video Link (7 min)
- Video showing this error and how to resolve it
This error will occur if the Renesas e^2 debugger is not found on the development system
When trying to debug the application (clicking on the small green bug icon in e^2 studio) the following dialog is displayed . . .
- Verify that the RASynBoard is correctly configured to enable the debugger
- Make sure to use the USB-C connector on the I/O board
If you still can't connect to the debugger, verify that the driver is correctly installed on your development PC
- Verify the hardware configuration as above
- Open your device manager and look for the Renesas USB Development Tools --> Renesas E2 Lite device
- If not found . . .
- Try to reboot your PC
- Try reinstalling the Renesas e^2 Studio application
When trying to flash a new image (*.srec) to the RASynBoard, the user sees the error below.
This is a known FSP issue. To resolve the issue start a new FSP project
- Launch the Renesas Flash Programmer (version 3.11.02 or later)
- Select File -> New Project, the "Create New Project" dialog opens
- Use the configuration shown, click on the Connect button
- You should see that the application connected to your RASynBoard
- Flash the board
- Select the Operation Tab
- Browse to and select the *.srec file to load to the board
- Click on the Start button
- The image is flashed to the board, and you should see the application update as shown below
