Category: Jiamin’s Status Reports

This week and the past week was spent in preparation for the demo that was on Monday, and making the final presentation slide deck for next Monday. We all met as a team as we continued to finish integration on the hardware side. Majority of the progress can be seen in the post titled “Team Status Report for 11/25”. Everything on the hardware side is basically done and I have given Iris the .bin file needed to flash the Nucleo, just in case if she needs it. I worked on on wiring the LEDs to signal I2C transmission to the Jetson Nano, and I have been coordinating with my friend at TechSpark to complete the enclosure. The RFID was being finicky if an user actually taps and touches the device since I think the expansion board becomes loose from the Nucleo board, and thus we made a clear acrylic enclosure for the RFID tag. I also painted our enclosure black so it has a more slick look. Rest of the time, I have just been helping Iris and Minji out when possible with the Jetson and Cloud stuff. Before we all left for break, we filmed a couple clips that we plan to use in our final presentation and final demo video. Overall, progress has been on track, and next week will be spent working on the blog post and final video.

 

This week I contacted my friend who worked at TechSpark to help us out with our enclosure idea. We got all of our final pieces in, including the display monitor and power strip, so we were finally able to get the dimensions that were needed. The detailed photos are shown in this week’s team status report. Iris and I met to finish the integration between the Jetson Nano and Nucleo. We were finally able to get the strings to concatenate correctly on the Nano. For some reason when we are inactive for some period of time, we would lose the first byte of the string UID. We explored the possibility of a timing issue and considered maybe having the Nucleo do a memory write to the Nano. In the end, we modified the code to be able to get the correct string by having the user tap twice. With this change, we needed something to indicate to the user the read and sending of the string UID was not successful. Thus, tomorrow I will go into HH with the team to wire LEDs to a breadboard and to the GPIO pins of the Nano. Since we will be going into lab tomorrow, I will also test out the “wake up” signal again. I am still on track since most of the things on the hardware side is done, we are just figuring out the rest of the pieces for things to come together during integration. Next week, I am hoping we will have the CAD files for the enclosure ready but not sure if we will be able to laser cut the prototype. I heard from my friend that TechSpark is closing for students due to increased COVID cases 🙁 so we might have to reach out to a staff to do the laser cut for us. I will continue to work with the team as issues come up, and I will also see if Iris and Minji need any help on the IoT side.

This week was spent in preparation for the demo that was on Wednesday. For the beginning of this week, I started looking into how to implement SPI and UART for serial communication. But in the end, we stuck with I2C for the Nucleo to Jetson Nano communication. I spent a good amount of time in HH debugging with an RPI 4 to figure out i2cdetect by testing with internal vs. external resistors, the voltages, and signals of different things using an oscilloscope. There was weird behavior with the RPI with setting the slave address of the Nucleo and trying to i2cdetect. But when we tried this directly with the Jetson, it worked on both busses! We were able to run i2cdetect on the Nano with the intended slave address. I was able to HAL_I2C_Slave_Transmit() the UID of the RFID tag. This was originally tested in a separate environment so then I also took some time integrating I2C peripherals and logic into the actual NFC environment. I tested this RFID tag reader with the CMU student ID and it is able to read the tag of the CMU ID. With the FSM I wrote last week and a little debugging, we were able to get things to transmit. We also tested slave receive, in the case that we plan on having the Nucleo receive a signal from the Jetson. However, there was some strange behavior when Iris and Minji tried to concatenate things on their end, so that will require further debugging. In addition, last week I thought I was able to get the disable auto power on for Jetson to work, but I realized I made a mistake. It turned out that I was sending 3.3V to the GND pin of the Jetson. While it worked for the 2-3 tries I attempted, it didn’t feel stable as a long term solution. After I tested things out the a voltmeter and with the intended voltages on the pins, I was no longer able to get the “wake up” signal to work. Overall, I am on track since I was able to get all the functionalities I wanted to get done on the Nucleo except for the “wake up” signal. Next week, I will look more into this logic and start thinking more about the enclosing we want to make for our whole system. We talked with TechSpark, and they suggested that we can look for individual enclosing that already exists online, but I think we will have to design our own to account for the temperature sensor and Nucleo expansion board.

This week I worked on writing an fsm logic for reading, detecting, and sending the uid with the Jetson nano. I also wrote some dummy data to test that global signals within the files are working as expected. I wrote up all the code needed for the wake up signal and I2C at the beginning of the week. I met up with the team on Friday to integrate the system. The wakeup signal logic worked as expected but it would reboot the entire system if we didn’t keep it shorted. Thus, we will need to re-adjust the function of our wake up logic to maybe something like: turn off the Jetson after X amount of time at some idle state. The big issue right now istthat I2C integration was not successful. I was never able to detect the Jetson nano when wired with i2c. However, I was able to detect the temperature sensor and an arduino uno’s i2c. I am not sure what is causing the issue with the nano i2c. Another issue on the Jetson Nano side is that the second set of I2C busses does not work. The temperature sensor right now works using bus 0 on Jetson Nano but it breaks when using bus 1. That is also something we will have to debug if I can get I2C to work on bus 0 of the nano with the nucleo board. Due to these issues, I am slightly behind schedule. Next week’s goals are to try working with an RPI 4 to see if the Nucleo can detect the RPI. I will also look into SPI and UART transmission more. SPI is not looking like a good option right now due to the lack of documentation with the Jetson. UART does not provide bi-directional communication.

I got the NFC05 expansion board from school on Monday and started integrating the drivers and files from the Nucleo L764RG with the X-CUBE-NFC05. This took some time since some files were different and I had to look through individual files and make sure I placed the right things in the correct folder path. I also got the platformLog() to work so I don’t have to use my own printf() function anymore. With the tag bags I bought, I was able to start scanning on the expansion board. The UID also reads successfully! It matches the information that is shown in the NFC Tap app, when reading the tag on the phone. I started looking into the I2C protocol and how to handle that on the Nucleo. It does have HAL_I2C drivers so I will definitely be using those functions. Although when setting up the i2c peripheral in the Cube IDE .ioc file, it tries to regenerate code to match the new set peripherals, which messes up the RFID scanner code. Next week, I plan on working in a separate environment to get the i2c to work with the Jetson Nano, before trying to integrate with the RFID scanner environment. I also might need to buy some wires for next week to do connections between the Nucleo and Jetson. I will have to work with Iris to make sure the Nano has the i2c and GPIO permissions set up so that it can actually detect the Nucleo. We updated the Gantt chart to better reflect our progress (see team status report) and I am still on schedule. I am aiming to complete i2c by next week.

This week was spent making sure that the current NFC02 board is incapable of performing the functionalities we wanted and figuring out how to do print debugging with the Nucleo board. Last week I was able to get blinking LEDs but since I didn’t have any NFC compatible devices I wasn’t able to fully test out the program. I borrowed my roommate’s phone and found some weird inconsistencies with the NFC code provided vs. what I have changed. I read a lot of code and documentation for NFC02 to confirm that we needed to submit a new purchase request for the NFC05 expansion board.  I did a search for “id” in the documentation and all I found was things related to getting the driver id, but none about the card/device id. NFC05 does have the RFAL library that seems to be able to read the id of  the card/device. I then started looking into the files provided in the X-CUBE-NFC05 and saw that they use this platformLog function. However, this type of debugging isn’t automatically enabled so I have been trying to look into print debugging with the IDE and seems like using puTTY will be the most ideal option. I got printf() to work by using the HAL library and UART. 

Progress is still slightly behind schedule because I had to purchase a new board. But I am confident that I can catch up to the current timeline once the new board arrives. I am hoping that it will arrive by early next week. This way, I can set up UART to get print debugging to work. More research will be done since the demo code uses platformLog, so I will play around with that. With print debugging working, I hope I can finally read the UID of the tags I got

This week I was finally able to get the drivers for the X-CUBE-NFC02 to work with my Nucleo board. I was able to successfully run the project demo in my own workspace. I made sure I added all the paths to my .h files, edited all the original NFC02 includes to my board (stm32l4xx), added the library folder path, and other necessary files that needed to be included in the “Core” folder. The main issue that I encountered last week was solved by a simple #define. It didn’t originally cross my mind since I didn’t see in the project demo where they included this line. After I got the X-CUBE-NFC02 software to work, I started to think about how I can retrieve a card’s unique ID (UID). At first I thought I could do this by integrating the CR95HF drive with it, but it led to more driver incompatibility issues. I did a search to see that the documentation for NFC02 never even mentions this driver while the NFC03 board does. Then I saw that NFC03 and above boards have this RFAL library that my NFC02 board does not have. I read the provided documentation in NFC02 to see if there is a way to get the tag UID and there is a function called “M24LR_i2c_ReadDSFID”. The documentation is not very clear and I still need to do more research on M24LR drivers to see if  it can do what I want. I did take a look at the X-CUBE_NFC05 software package because it was tested with STM32L4xx drivers. In the demo file provided, it seems that the RFAL library provides an nfcDevice struct with a pointer to nfid. I might need to consider upgrading the NFC expansion board if the M24LR functions cannot provide me the information I need. Additionally, I spent a good amount of time looking at how to do print debugging in the STM32CubeIDE. I think I got something to work but it’s not the most ideal situation. I also worked on the design review document this week because the deliverable is due Monday. 

My progress is behind schedule because I just ordered the ST25 NFC tags last week and they were delivered to Pittsburgh. I am flying back tomorrow to stay for the rest of the semester. I also put in an order for new tags because the tags I last ordered are type 4 instead of type 5. By next week, I am hoping I can read the UID of the tags with the NFC02 board. If I deem this is incapable of doing, then I need to do some serious research and put in an order for a new expansion board. I will also meet up with Iris and integrate the temperature sensor on the Jetson Nano. 

I got my Nucleo and NFC boards in the middle of this week. I have been trying to get the boards to work together, and still haven’t had any luck. I was able to get the binary file from the demo to work by dragging it straight to the board. I also followed the tutorial for the Nucleo board to program the blinky light. I followed and watched some tutorials on how to use the STM32CubeIDE. I read up on HAL drivers and did some reading into the X-CUBE-NFC02 documentation about the functions that will be available to use. Seems like I will be using the NDEF library available to us. I ordered the ST25 NFC tags. Hopefully I will get those soon when I go back to Pittsburgh next Saturday. The issue with the drivers on the NFC is that it was only programmed to work with 2 types of boards within the STM32 series, and the documentation claims that it works with any type of STM32 board. But I still can’t get the files to compile. I am getting make errors, so I will have to look more into that next week. 

The progress is still on schedule. By next week, I would really like to get the drivers for the NFC to work with the Nucleo board. If I can get that to work, then I would like to use some of the demo code and play around with that to learn more about the libraries.

I submitted the order form for the STM32 Nucleo-64 Board (NUCLEO-L476RG) and the NFC reader (X-NUCLEO-NFC02A1). I read some documentation related to both of these boards and the steps needed for initial setup. I downloaded the STM32CubeIDE and the other software that are needed for the NFC board. I decided that I will most likely code in C instead of C++ for the Nucleo board, since I am more familiar with C. I also bookmarked some good quick start guides and YouTube videos that will come in handy when the boards do arrive. Aside from these 2 boards, I did a little deeper digging into how to turn on/off the Jetson by using the Nucleo board. I originally only did research on Jetson Nano A02 boards, but we purchased a B01 board. The notable thing was that instead of J40 I will be using the J50 headers. The way to disable auto power on and initiate power seems to be utilizing the same concepts. Pins 5 and 6 will need to be connected with a jumper to disable auto power on. Pins 11 and 12 will need to be shorted for a momentary switch to serve as a button to initiate power on when the auto power on is disabled. One thing I’m still a little unsure is how I will short pins 11 and 12. I will have to wait until I am back in Pittsburgh to fully test out some of my ideas.

My progress is on schedule since we planned in the Gantt chart that while we wait for our supplies to come, we will just do research and gather information that will be helpful to us.

If the board can come by next week, I would like to make sure that the Nucleo board and the NFC reader are initialized correctly, so that the NFC is working properly. I would like to write some initial code and tests to make sure the NFC is doing what is expected, and maybe just find some sample code online to test out some of the features of the Nucleo board. I would like to familiarize myself with the hardware and the STM32CubeIDE.