USB not recognized after flashing the firmware

[ksumit12]

i have a custom pcb that uses renesas mcu same design as the provided reference CANapp board. i was successfully able to flash the mcu in bootloader mode by pulling down the MD but then when I restart the board I don't see any com port or devices being recognized even AFBR-s50 Explorer app doesn't show any devices to connect to.

here I used the last file to flash is that the correct one?

here is the schematic for reference I don't thing it should be a hardware issue but still I will recheck ldo and all the mosfet.

[c-berger]

Hi there,

the Renesas does not has a build-in Serial-over-USB bridge and thus it can not enumerate as COM port on Windows. Instead, you need to connect an external Serial-over-USB bridge (FTDI, for example Adafruit FT232H) to access the serial/UART interface. This is documented here:
https://broadcom.github.io/AFBR-S50-API/reference_board.html#reference_board_uart
Note that you need to flash the AFBR.S50.ExplorerApp.v1.5.6_RA4M2_UART.hex file to use the UART interface.

If you instead intent to use the native USB connection, the correct firmware would be AFBR.S50.ExplorerApp.v1.5.6_RA4M2_USB.hex. The Renesas MCU should then enumerate as an AFBR-S50-EK under the Measurement and Control section in the Device Manager.

Please note further that the CANApp is not able to connect to the Explorer GUI as this is a completely different project and does not contain the communication protocol required for the Explorer GUI. The same is true for the example app. The later only streams data via the UART (again, an external FTDI is required). The CANApp is only a simple demo that contains very simple CAN commands to start and stop measurements as well as receiving distance values. It is only meant as a quick start to implement your own CAN messages.

If you still have issues with the correct (USB) firmware and can not connect to the board, it probably is a design issue on your custom board.

[ksumit12]

thanks for the explanation i tried this with AFBR.S50.ExplorerApp.v1.5.6_RA4M2_USB.hex , indeed I was able to see AFBR-S50-EK under the Measurement and Control section in the Device Manager but when I connect tired to connect the explorer

then I am getting

for the AFBR.S50.ExplorerApp.v1.5.6_RA4M2_UART.hex firmware I tried two different USB to serial one was ft232h and other was cp210x all I can see is there com port

for both the firmware I am getting no SCI devices found. i know there might be a possibility that the design was incorrect but I checked this again and again also for the USB and gpio pin there are directly connected to the connectors so if mcu is powering on correctly then this connection should also be correct.

[c-berger]

The USB connection is now good, however, the MCU to AFBR-S50 connection fails. The firmware tries to initialize the device upon initialization and if if does not succeed, the resulting error is "no free devices found" (as there are 0). So I recommend to double check the power supply and SPI connection to the sensor. I have not found any error with a quick glance at you schematic though.

Maybe it helps if you probe the first view SPI commands after powering the device. There is a connection test going on where the firmware tries to probe connected devices. Have a look here for the description:
https://broadcom.github.io/AFBR-S50-API/faq.html#autotoc_md73

[ksumit12]

thanks for the quick reply so now mostly the issue is with the PCB and the sensor itself ?! using oscilloscope to view sensor's spi pins I should be able to see some waveform which if decoded should translate to these
Writing a test pattern to register address 0x04:
MOSI: 0x 04 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
MISO: 0x 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (or any other, depending on the current state of your device)
Clearing the test pattern at register 0x04, read back of test pattern 1:
MOSI: 0x 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MISO: 0x 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
Clearing the test pattern at register 0x04, read back of test pattern 2:
MOSI: 0x 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MISO: 0x 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?
I'll try this first another thing is that how much voltage there should be for the spi pins while I was testing the PCB I realised that diode near ldo is causing 0.3 voltage drop well it is in the operating range of mcu but is it for the sensor?
does API has something that lets you interact with the spi pins of the sensor or maybe write these test sequence manually and then verify it on the oscilloscope?

[c-berger]

Yes, you're right. The issue is probably with the sensor. Since you're using the same MCU with an unchanged firmware and USB connection can be established, there must be some issue with the sensor or the connection.
The power supply can be the source of your problem too. If there is a voltage drop the device will execute a power-on-reset (POR) which puts some registers back to their default values.
That being said, it is also a good idea to monitor the power supply near the sensor and make sure it stays stable within the allowed voltage range. Please refer to the datasheet for the exact values, but the POR can happen quite easily...

[ksumit12]

i couldn't really find anything about at what voltage power-on-reset gets triggered but I checked my pcb and all the +power supply pin is giving out 5.095v(VDD), for all the SPI pin its 3.028v and for IRQ its 0.015v. i checked them constantly with different condition like when powered on and short circuit (tried this on spare PCB without sensor (obviously voltage drops and not increase more than 5.5v limit)). anyway is there a way that I can make sure that the sensor itself is not defective using just dmm? i don't know if it will work or not but right now I am trying connect the board via PCB and trying to read spi lines via ftdi might not work but maybe I can try to replicate those test sequence .

from pyftdi.spi import SpiController
spi = SpiController()
spi.configure('ftdi://ftdi:232h/1')
slave = spi.get_port(cs=0, freq=12E6, mode=3)  # CS0, 12 MHz, Mode 3
while True:
    data = slave.exchange([0x00] * 16)   
    print(f'Received SPI data: {data}')
    import time
    time.sleep(1)

[c-berger]

The IRQ pin should not be asserted unless a measurement was triggered. So I'd expect it to be at a high level when powered.

The code looks reasonable. Make sure the mode 3 is correct (CPOL = 1, CPHA = 1), see https://broadcom.github.io/AFBR-S50-API/porting_guide.html#autotoc_md29
Maybe you can temporarily reduce frequency for testing in case of trouble.
Also, you need to add the address to the slave.exchange function. So it should be 0x04 + 16 bytes of data. You can write any values to that register and it should read back on the next slave.exchange.
Note that the success of this test does not guarantee the device is OK. However, it will make sure the SPI setup and connection is good.

[ksumit12]

i was wrong about IRQ voltage it was high(3.028v), miso voltage was around 0.015v and this was on different PCB which didn't had a soldered sensor on it so I am assuming this is correct since no slave is connected. tried the FTDI thing and couldn't read anything from the mosi so now I tried to use dso and got some reading which looks weird doesn't looks like spi

here ch1-clk ch2-mosi ch3-cs ch4-miso considering that test sequence would go for a fraction of sec does this look ok? after this signals were stagnant and in WAIT trigger was set to ch3 falling edge. another thing I wanted to ask is I manually tried to set CS pin by changing R_IOPORT_PinWrite(&g_ioport_ctrl, (bsp_io_port_pin_t) SPIx_CS_PIN, BSP_IO_LEVEL_HIGH); to LOW in platforms/driver/s2pi.c I don't know if this should have worked or not but after building the firmware it didn't had much effect. i don't have renesas debugger to do hardware debug directly would have made life much easier. are there other ways just to check if spi lines on PCB is working or not?

[c-berger]

Hi, thanks for the answer. Unfortunately, I can not completely follow your comment. From the provided screenshot, I would start with the CS signal as it looks a bit noisy (crosstalk from the clock signal?) and also does not go from high to low whenever a new SPI transfer starts. So probably you need to debug your PCB first.
Here is what I would expect on the SPI signals.

1 CS, 2 CLK, 3 MOSI, 4 MISO
Note the CS going from high to low when the transfer starts.

I don't understand what you changed in R_IOPORT_PinWritef.

[ksumit12]

What’s the settings of the dso here? By this R_IOPORT_PinWrite i meant i was manually trying to set cs pin low when argus_init() gets executed so i can atleast observe what’s happening with the cs pin because unless it goes low clock and other pins also won’t work. NVM I tried different dso and got somewhat similar results

cs pin seems to be working as it should be and clock line also seem fine but mosi line is not sending anything miso is as expected cause this is different PCB without sensor soldered on

[ksumit12]

i think this is it, the test sequence? although it's not decoding

[c-berger]

Yes, looks much better now. Probably MISO (red?) has some still some issues...