RX671 dev board PMOD support – Time of Flight and OLED display

Table of contents

RoadTest: Enroll to Review the Renesas RX671 MCU Eval Kit

Author: dbkincaid

Creation date:

Evaluation Type: Evaluation Boards

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Various higher-end Microcontroller boards like MSP430, lower end boards like RP2040

What were the biggest problems encountered?: The software development platform environment has very recently been updated, and many of the changes are so different that I was not able to follow some of the source material I was counting on (older project designs, youtube videos, etc). The new changes make sense, but there are still some unintuitive steps to configure the hard IP (I2C and SPI ports). I could not get the SPI port to function (Chip Select would not toggle)

Detailed Review:

Intro

Some time back I had purchased Time of Flight and OLED display PMOD boards.  I did not end up using them on the project at the time, but I have been curious about the accuracy of the ToF module.  I also want to see how easily the OLED display integrates into the types of projects I like to implement, mainly small embedded designs with some Network connectivity and/or HID.  The RX671 development kit looks like a great platform for me to integrate these devices into a functional project and explore the RX family of devices with some hardware I have on-hand.  I am also intrigued by the USB 2.0 Full Speed support as Device, and as Host, but I will not get to this function in the project below.

Procedure (out of box demo)

⦁ First order of business get the example design from Quick Start Guide running. The board will attach to my PC as a USB serial port from the board debug port, running at 115200 8-N-1 None, verify the terminal application is working.  
⦁ -> Got it working with minimal fuss, the example design is nice in that it utilizes some LEDs, buttons, and also has a serial terminal running all in a sequence.  It is a great example to start from.

Procedure (edit demo and run)

⦁ Continue the example where I import the design and rebuild. Make some adjustment to the program (text in terminal, etc), then run through Debug mode and Release mode. This will help familiarize me with the dev environment.
⦁ -> Got it working after downloading the Windows 10 tools.  I wanted to use an Ubuntu environment, but the current demo using E2 Studio is not yet fully supported.  I found that there are several toolchains available to program the device.  This is great for the long-term, but my interest was to edit the included demo, so I needed to utilize E2 Studio on Windows 10. 

a. Download e2 studio 2023 10 Windows 10
b. Download CC-RX V30500 setup
c. Download quickstart code

I made a simple change to the text in the serial port display in the menu_kis.c file.

Procedure (I2C communication)

⦁ I had hoped to copy in some I2C code from another example to get my TOF sensor running, but I did not find a good recent reference for I2C in the new E2 Studio.  Anything older than a few months was in the old version of E2 Studio and was not helpful at all.

So, I carry on and see what I can figure out.  I used the Smart Configurator to assign pins to a simple I2C port.  When I export it will build a set of API drivers for me with a .h and .c file.  

(Pins Tab) I configured SCI11 as SSCL11 / SSDA11 pins 69 and 78 respectively.  These match the PMOD2 I2C assignments in the dev kit, and matching my PMOD TOF I2C pins

image

I configured the I2C port (Component tab) for 100kHz, and set ACK/NACK interrupts and Callback functions enabled.

image

In the code, the idea is that I set up the I2C port in main() and then send transactions in the interface code.

* Changes to menu_main.c 

#include "PMOD2_I2C.h" // I2C Port on PMOD2 pins

add (will be explained later)

volatile int8_t I2C_busy = 0;


main() function

R_PMOD2_I2C_Create();
R_PMOD2_I2C_Start();
before the user_init() call]

The settings for the I2C port were already established from settings in the Smart Configurator (speed, pins, etc)

* Changes to menu_kis.c

#include "PMOD2_I2c.h"

extern int8_t I2C_busy;

kis_display_menu() function
adjusted the do {} loop so that I could run code while idle on the 'KIT INFORMATION' sequence.
* My new idle case incremented a rolling counter, and set a GPIO of PMOD1 to LSb of the counter (to toggle it, I use this to trigger Logic Analyzer)
* I added the following code to perform a simple read transaction to the PMOD port through I2C

// This code is constantly looped (waiting for '1' or 'space' at menu)
R_GPIO_PinWrite(PMOD1_D_Cb, (counter&0x1)?GPIO_LEVEL_HIGH:GPIO_LEVEL_LOW);
i2c_data[0] = 0;
i2c_data[1] = 0;
i2c_data_in[0] = 0;
i2c_data_in[0] = 0;
R_PMOD2_I2C_IIC_Master_Send(0xAE,i2c_data,1);
while (I2C_busy) { nop(); }
R_PMOD2_I2C_IIC_Master_Receive( (0xAE|0x1), i2c_data_in, 1);
while (I2C_busy) { nop(); }
sprintf(g_print_buffer, "\r%d read 0x%02X", counter++, i2c_data_in[0]);
console_write((void*)g_print_buffer);

The device address is published as 0x57, but they do not shift for RnW bit, the E2 API calls expect the address is already shifted, hence 0xAE (write) / 0xAF (read).
I still had a bit of confusion getting this going, but I soon realized that the transaction request to the I2C port is not a blocking call, meaning it does not wait for completion to send another transaction, so I can just jumble a transaction in-flight.
This is great if you want to dispatch communication to many ports and then gather results after, but I am only talking to one peripheral at a time for now.
I had to add a 'I2C_busy' flag to halt execution until it completed, as shown with the while (I2C_busy) { nop(); }

*In PMOD2_I2C.c

extern int8_t I2C_busy;

I added I2C_busy=1 the the beginning of _Master_Send and _Master_Receive, and I added I2C_busy=0 to the callback functions (they are automatically called by interrupt upon completion).
There is a pretty good doc that shows a flowchart https://www.renesas.com/us/en/document/apn/rx-family-simple-i2c-module-using-firmware-integration-technology
There might be a better way to implement this, but I didn't want to search forever to understand the status bits, and the callback functions are already set up.
The code sends an I2C read transaction to the Device ID register on the ISL29501 device (TOF sensor), and the expected response is 0x0A per the datasheet https://digilent.com/reference/_media/reference/pmod/pmodtof/isl29501.pdf
image
The transaction on the SDA / SCL pins looks like this. The center section where both lines are high at same time is the dead-time between the _Send and _Receive.image

Procedure (SPI Communication) 

⦁ Like my plan for I2C I had hoped to utilize some reference I found on Renesas for interface with a Serial LCD similar to my board, but I found that the new E2 Studio drivers for SPI are very different with initialization.  I find the hardest part of the IP is figuring out how to correctly set up the handles (pointers) so that the drivers are connected to the hardware and configure it.  And, just like my prior plan I didn't find anything particularly helpful.  

Once More Unto the Breach

After spending quite a lot of time porting a library for use with the display I have what almost looks like an SPI transaction running on SCI10 (SPI port that maps to PMOD1).  I do have an issue though. 

When I select the SS10# (Slave Select aka Chip Select) signal it maps as an input in 'Pins'.  This is not correct, I am trying to implement a send-only Master, but I expected the master to control Chip Select.  It does not control the pin, so I am stuck.  No problem, I just change the pin to a GPIO and I can manually control Chip select. 

Here is where I completely fell apart.  My project broke when I regenerated the code, now there are many broken support code files like r_sci_rx.c.  I went through the compile problems but I am completely lost how to fix the issue.  I don't really want to bit-bang an SPI port on a board like this, it doesn't make sense unless I can enable the SPI peripheral correctly.

Conclusion

So, unfortunately this is where my project will end, I am interested to see if anyone else was able to implement an SPI port, or if I might get some feedback from Renesas on the issue.

image

Anonymous
  • The SS# pin of RX671 can only act as input to judge whether any transmission is going or not in master mode. Only way to ouput SS signal is using GPIO port as you did. You can refer to RX671's UM section 35.8.2 for detail.