what will make a USB-CDC/COM port crash/disconnect?

Having a weird issue, code is too long to post.  Using SSP 1.6.3 on S5D9 and have an error I can't understand.  

Briefly, a host program sends commands to the S5, and it processes them and sends a response.  So 1 line code of reading, many lines of writing replies.

There are some 'unit functions', commands that do a simple task and then respond and system waits for next command.  There is also a 'recipe' that combines several of these unit processes in sequence.

If I run the combined recipe, everything works: I can run the recipe or the individual processes one by one and all works.  However, if I try to run the unit processes individually *before* running the recipe, the USB/COM port communications crashes/disconnects and then reconnects (when using Tera term).

This may seem like something is not not getting set/initalized, but I've been through all of them and the unit command is processed and then followed by crash.  I cannot find a variable that is different in the two cases.   Moreover, there is nothing that would crash the USB/COM port.... unless some unrelated activity would do so (math error but i've checked for that).

Sorry for the code-less explanation but this is getting impossible.  Things I've done:
-changed all communications from NO_WAIT to WAIT_FOREVER; tried locking the USB port while it processes commands; added and removed delays suspected of hardware issues; added diagnostic messages and compared variable values this way.  (No debugger but can populate JTAG interface).

Any thoughts appreciated!!

  • Hi cam, 

    I have no experience on why that issue is occurring. Let's wait for others more knowledgeable about the matter to comment about this. I can suggest that you can insert a file link on this thread instead of directly pasting it so others can check your code.

    RenesasRulz Forum Moderator


  • I may need to do that eventually but it's complex so I would need to edit out the unrelated things.

    but further testing this morning revealed the following:
    it's not the USB/COM resetting, the S5 itself is rebooting!

    after initialization the code goes into a while(1) loop to process incoming commands from the host like this:

    while (1) //main USB loop
    // wait for data
    err = g_sf_comms.p_api->read(g_sf_comms.p_ctrl, (uint8_t *) cmd2, 72u, TX_WAIT_FOREVER);
    set_pin_level (board_blueLED_pin, led_on); //blink when processing a comm
    (....case statements for different commands)

    more exactly it's rebooting on the g_sf_comms.p_api->read line.  what is extra strange is it only reboots when returning from one particular command (PWM activation) and not any of the other 45 commands.

    what would the appropriate things to try here?  

  • Hi Cam-

    It has been a while since you posted. Did you figure out what was going on? Only a few things can cause a reboot, so I'm guessing you were able to track it down...

  • It's still somewhat bizarre.  I didn't determine root cause but I found a bandaid.

    to recall, I had a multi-step recipe in code that would work, but when I manually activated these steps one by one, it would fail and reboot.

    it seemed related to the last step, which is activation of a PWM.  
    -in manual mode the PWM would turn on and immediately turn off again, disturbing something in the code and caused a reboot.  i couldn't measure it but I think the PWM turned on with 100% duty instead of 20% as instructed.
    -in recipe mode, the code is in a loop and activates the PWM repetitively every 20 milliseconds until the code sees confirmation the PWM is running.  (specifically the PWM activates an RFPA which drives a plasma, so this step repeats until it sees a signal on a photodiode.)

    i also think part of the issue is a hardware bandaid (design error: a GPIO and a PWM were mixed up, so a jumper was installed and this [different] PWM is set to 100% to emulate a GPIO).  this was fixed on latest board turn so not too worried about it.