cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1

KyTr_1955226
Valued Contributor

Hi all,

I've got a bit of a unique issue on a project that requires a USBUART bootloader.  The bootload process itself I have no problem with, I have loaded new firmware using the USBUART with no issue.  Where the problem comes about it in regards to how application code on the host side deals with the sudden loss of the COM port when jumping to the bootloader and back to application code after loading.

Using the standard .NET System.IO.Ports, I can say for sure that it really REALLY does not appreciate the loss of a COM port during runtime.  Not normally an issue with a hardware serial port since they don't normally disappear from the device list, but with USB UARTs this suddenly becomes a possibility, and becomes an issue for my bootloader host.  Typically on a UART bootloader, I have a specific command that the PSoC receives that forces a call to Bootloadable_Load() which jumps it to the bootloader.  The problem is the USB UART device will disappear from the list for a short time before it re-connects in the bootloader firmware.  At this point the application can run into problems trying to use the port for the actual bootload process.

Maybe it's a longshot, but is there any possible way to prevent this loss of the PSoC5LP USB device when jumping to the bootloader?  It would make things much smoother if possible.

0 Likes
1 Solution
Aashita_Raj
Moderator
Moderator

Hi @KyTr_1955226 ,

As per my understanding, it is not possible to prevent the loss of COM port when jumping to the bootloader and back to application code after loading. This is because, when there is a transition from one program to another, the execution begin from the main() function and then the USB enumeration takes place with the help of start-component API. Therefore, every time you switch to the application code the USBUART is not enumerated and hence it will not appear as a COM port.

Hope this helps! Please let us know in case of any further query.

Best Regards,

Aashita

 

 

View solution in original post

0 Likes
3 Replies
Aashita_Raj
Moderator
Moderator

Hi @KyTr_1955226 ,

As per my understanding, it is not possible to prevent the loss of COM port when jumping to the bootloader and back to application code after loading. This is because, when there is a transition from one program to another, the execution begin from the main() function and then the USB enumeration takes place with the help of start-component API. Therefore, every time you switch to the application code the USBUART is not enumerated and hence it will not appear as a COM port.

Hope this helps! Please let us know in case of any further query.

Best Regards,

Aashita

 

 

View solution in original post

0 Likes
KyTr_1955226
Valued Contributor

Ah well, had a feeling this was probably the case, was hoping maybe for some clever way to keep the device enumerated through the jump.

I guess time to try and figure out a workaround from the PC Host side.   Likely going to have to split the loading procedure up in some way.  Something like:

  1. PC Host sends enter loader command over VCP.
  2. PSoC sends acknowledge, waits some period of time to allow PC host to cleanly close the COM port while the VCP device is still present.
  3. PSoC Jumps to bootloader.
  4. PC Host re-scans COM ports.
  5. PC Host initiates bootload on user input.
  6. After bootload, PSoC waits a period of time to allow PC host to cleanly close the COM port while the VCP device is still present.
  7. PSoC Jumps back to application firmware.
0 Likes
KyTr_1955226
Valued Contributor

Just a little followup on this.  I did manage to get .NET to not throw a fit when jumping from the application to the loader via a delay as mentioned in step 2 in my previous post. 

Still can't get it to reconnect clean when it resets after the bootloader is done.  It will still show up in Device Manager, but for whatever reason applications aren't able to access and use the virtual COM port until it has been disconnected/reconnected.  Very much seems like a possible driver/windows specific issue, which I unfortunately can't do a whole lot about.

Might just have to add a step to the customer bootload procedure to have them disconnect and reconnect the USB cable after loading.  Annoying, but there doesn't seem to be any real fix I can find.

0 Likes