Debug 2 boards on one PC (Error in services launch sequence)

[DarrenD]

I have 2 boards S32K146EVB-Q144 with 2 instances of S32 Design Studio for S32 Platform and 2 USB connections, one per board. Both boards light up.

The first S32DS instance uses a target configuration looking at "PEMicro Interface Settings" port "USB1 - OpenSDA (xxxxxxxx)" with default "GDB Server Settings" port numbers 6224 and 7224.

The second S32DS instance uses a target configuration looking at "PEMicro Interface Settings" port "USB2 - OpenSDA (yyyyyyyy)" with modified "GDB Server Settings" port numbers 6225 and 7225.

I can click the 2nd instance S32DS "bug" debug icon, connect to USB2 and debug the app normally.

I can then click the 1st instance S32DS "bug" debug icon, connect to USB1 and debug the app normally. I can also debug the USB2 app normally.

I can then update code in the USB1 instance, click the "bug" debug icon to recompile and reconnect to USB1 and debug the app normally. I can also debug the USB2 app normally.

However, if I then update code in the USB2 instance, click the "bug" debug icon to recompile and try to reconnect to USB2 I get the error message

Problem Occurred

'Launching <my_project>' has encountered a problem.

Error in services launch sequence

Clicking Details I then get

Error in services launch sequence
PEmicro GDB Launch Failure : The GDB Server was not able to establish a connection to the target processor. Please check your connections and power. Verify that the launch settings in the Debug Configuration are accurate.

To update the USB2 instance I need to disconnect USB1 instance, connect USB2 instance, reconnect USB1 instance.

It seems to be that USB2 can ONLY connect if USB1 is not connected.

What am I doing wrong?

Thanks

Darren

[DarrenD]

Thanks for the speedy reply. If I don't respond for a while it's because I am going on holiday for a few days.

I successfully connected to USB2 instance, then successfully connected to USB1 instance (in 2nd S32DS instance). I then clicked "Debug Configuration" on USB2 instance and this is what I get (I clicked the port drop-down to show you all available ports)

I then selected my USB2 port

Then I click the "Debug" button at the bottom and, after recompiling, eventually get this

[juan_see]

Hi @DarrenD 

In the port selection, whenever you see a "[Currently Open]" next to the selection, that means that the OpenSDA is still active. 

Can you please make sure you terminate your debug session before clicking the "bug" debug icon?

[DarrenD]

I can terminate my USB2 connection as you suggest here. However, that will not allow a valid connection since I still have "[Currently Open]" on by USB1 connection. If I terminate my USB1 connection then I can make a correct USB2 connection. This is the situation that I described in my original post.

When using a single board environment (so only USB1 exists) there is no need to terminate the USB1 connection. I don't understand (other than an IDE bug?) why I need to terminate USB1 connection before I recompile/reconnect a USB2 connection.

Situation 1 - USB1 disconnected, USB2 disconnected

I can freely connect to USB2

Situation 2 - USB1 disconnected, USB2 connected

I can freely connect to USB2. Situation 1 and 2 mean I can always re-connect to USB2 if USB1 is not connected.

Note, although I have "[Currently Open]" on USB2 (and importantly, no such text on USB1) I can connect again without the need to terminate my USB2 session. This is equivalent to a system with only a single board, a user can connect a debug session, edit code, then re-connect (which forces the recompilation, an automatic termination and then download to FLASH/RAM).

Situation 3 - USB1 connected, USB2 disconnected

I cannot connect to USB2. The USB1 has "[Currently Open]" but not the USB2 session.

This means that I must connect to USB2 first.

Situation 4 - USB1 disconnected, USB2 connected

I cannot connect to USB2. The USB1 and USB2 both have "[Currently Open]".

Note, to get into this situation I would have connected to USB2 then connected USB1.

I repeated the tests but swapped around the USB cables to the boards. I got exactly the same issues as above; the board connected via USB2 would never connect if the other board (USB1) was connected . I conclude that the issue is related to the USB port settings and nothing special with either of the boards. However, I don't know what I can do apart from my (very annoying) workaround of disconnecting USB1 session before recompiling/reconnecting my USB2 session (and then having to reconnect USB1 session).

[juan_see]

Hi @DarrenD, 

After you have updated the code in the USB2 instance and before you click the "bug" debug icon, can you please open the debug configuration dialog and make sure the correct port (USBn - OpenSDA (zzzzzzzz)) is selected? If you click on the drop down arrow, it should show both OpenSDA connections. 

[DarrenD · Accepted solution]

You may have found the perfect workaround - I think it's still a bug but it is a less intrusive workaround!

I had both USB connections made with code on both at breakpoints after I had set the LED to red on USB1 and blue on USB2. I then click the "Debug Configurations..." on USB2 connection. On the "PEmicro Debugger" tab I can confirm that both USB ports are showing and both have "[Currently Open]" and the drop-down on "PEMicro Interface Settings 'Port:'" is correctly showing my USB2. When I click "Debug" I get the error message, the blue LED is still lit. Clicking the "Debug Configurations..." on USB2 connection again the "[Currently Open]" has disappeared from USB2 and USB2 is still selected on the drop-down arrow.

I then terminated the USB1, reconnected USB2 and ran to its breakpoint to get the blue LED, reconnected UB1 and ran to its breakpoint to get the red LED (basically back to my starting point above again). I then click the "Debug Configurations..." on USB2 connection. On the "PEmicro Debugger" tab I can confirm that both USB ports are showing and both have "[Currently Open]" and the drop-down on "PEMicro Interface Settings 'Port:'" is correctly showing my USB2. This time, however, I change the port to show USB1 and then clicked "Debug". The connection was successful. However, it was not the board connected via USB1 but the USB2 one that got reset. The USB1 connection was unaffected and I could step though the USB1 connection code.

This is weird (well bugs usually are). To reconnect USB2 change the drop-down to USB1 and then the connection to USB2 works. As a bonus, the real USB1 connection is not affected. This is definitely counter-intuitive but does seem to work.

[edit] My only conclusion is that the drop-down USB2 is being treated as "the 2nd available USB connection and since my USB1 is [Currently Open], i.e. not available, my USB2 is now the 1st available USB and since there are no other USB connections there is no 2nd available USB, hence the error message". This is a completely wrong implementation (if that is how it is being handled) since the USB connection actually says "USB2 - OpenSDA (xxxxxxxx)". The "xxxxxxxx" is some sort of serial number for the board since if I unplug one USB cable I now have USB1 only and plugging into board 1 I get "xxxxxxxx" and plugging into board 2 I get "yyyyyyyy". Therefore, the USB connection knows which board it is talking to (xxxxxxxx or yyyyyyyy) so the IDE should be able to correctly identify the USB cable and/or board, hence why I call this a bug.

Thanks for pushing me to the least-effort workaround even though it is not the correct fix.

Darren