cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC Creator & Designer Software

New Contributor II

Hi,

We're using the PC Bootloader Host application to program a PSoC5 design via UART/RS232.  We regularly find that any of the ports detected that we select to use are unavailable showing "Access is denied" when nothing else is connected to them - in particular the USB serial ports we use.  The MiniProg ports also show access denied but that may be due to that fact that we have also use them to program to two PSoCs in the system.

The only way to get it back is to reboot the PC (Windows 10 Laptop) and then it will work for an indeterminate time.

Anybody else had the same issue and any ideas how to get around it?

Many thanks

0 Likes
Reply
1 Solution
Contributor II

You might be able to use the instructions here to determine which process is eating your COM port:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YGw9CAG&l=en-US

It does sound like the Bootloader Host in creator isn't letting go of the port, but this should let you confirm what process is holding it.

I've run into similar problems on systems with serial touch screen drivers installed.  They tend to immediately eat the first available COM port on boot rendering it unusable to anything else.

View solution in original post

0 Likes
Reply
9 Replies
Moderator
Moderator

Hi AnFa_301266​,

I tried to recreate the issue but I was unable to do so. To recreate the issue, I tried connecting to the COM port using the Bootloader Host tool when no services are connected to the port. I was able to connect to the device.

Then I opened a serial terminal tool, connected it to the COM port, and then tried accessing it using the Bootloader Host Tool, the same error showed up.

The only way to get it back is to reboot the PC (Windows 10 Laptop) and then it will work for an indeterminate time.

This makes me think - Could it be that some service is actually using the port?

The MiniProg ports also show access denied but that may be due to that fact that we have also use them to program to two PSoCs in the system.

Do you have PSoC Programmer open? If so, can you try closing the tool and connecting using the Bootloader Host tool again?

Would it be possible for you to share the project developed for the UART bootloader so that we can try and recreate the issue?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes
Reply
New Contributor II

Hi RakshithM_16,

Thanks for the quick comments.  The message does imply that it is in use elsewhere.  I've tried tracking down any other potential apps/services hanging onto the port but not found any so far.  Certainly nothing I have knowingly started.   It is interesting that the port is initially free - haven't determined the trigger that then causes it to be "access denied".  We haven't been using PSoC Programmer as we're programing/debugging from within PSoC Creator.

Once we get "access denied" here, the port also seems to then be unavailable for Hyperterminal/Termite so it would appear to be a system level problem.  I guess it might also be a permissions issue but not sure how to investigate that one.  Very irritating though!

I have a second live post which relates to issues that we are having with the UART Bootloader (when we can get access to a com port!) - it keeps failing part through the transfer - not directly related to this I think but really a bigger problem for us right now.  ('Packet length invalid:" during UART Bootload.")  Probably best to share the Bootloader project through that post as it is more relevant to that.

Any other thoughts would be appreciated.

Many thanks

0 Likes
Reply
Moderator
Moderator

Hi AnFa_301266,

Sure, please share the project on the thread and I will try to recreate the issue.

Can you please confirm if you are using a USB-UART component or a UART component + USB-UART Bridge?

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes
Reply
New Contributor II

Hi RakshithM,

This problem isn't really associated with the project, more with the Cypress supplied Bootloader Host application.  The port is listed in the port list but "access is denied" comes up when we try to select it.  We have scoured the PC for other running or background applications which might have taken control of the port but found nothing.  If we reboot the PC then generally it will allow us to connect the very first time.  Maybe it is the Bootloader Host itself that isn't releasing the port correctly when we exit the application?

We get the same problem on another laptop running Windows 7 (rather than Windows 10 on our main dev PC)  although, anecdotally, it seems to happen less often on the Windows 7 PC.

I can attach the project but I don't think that will help.

Any other ideas?

Many thanks

0 Likes
Reply
Moderator
Moderator

Hi AnFa_301266,

The reason I requested for the project was that we were unsure if you are using a USB-UART component. In this case, it might be an issue with the USB-UART configuration too.

I have reached out internally to check if others are able to recreate the issue.

Please try connecting the Bootloader Host program to MiniProg4 COM port and when the 'Access is denied' message comes up can you try connecting to MiniProg4 using PSoC Programmer and let me know if that works?

According to my understanding, immediately after restarting the PC, you are able to connect the Bootloader Host tool to MiniProg4 COM Port. But if you power off and power on MiniProg4 or you close and open the tool, you are unable to connect to the device again. Please let me know if this is correct

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes
Reply
New Contributor II

Hi Rakshith,

We're actually using USB-RS232 converters at the PC end and not using the bridge in the MiniProg4 - we have RS232 level shifting on the UART on our target PCB.

As mentioned in my reply to KyTr  we're starting to think that the Cypress supplied Bootloader Host app might be causing the problem but should hopefully find out tomorrow.

0 Likes
Reply
New Contributor II

Sorry - sent the message a bit early!  Was just going to apologise for the delayed reply - I've had a few days out for Christmas but will be back in the lab tomorrow..

Many thanks

0 Likes
Reply
Contributor II

You might be able to use the instructions here to determine which process is eating your COM port:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YGw9CAG&l=en-US

It does sound like the Bootloader Host in creator isn't letting go of the port, but this should let you confirm what process is holding it.

I've run into similar problems on systems with serial touch screen drivers installed.  They tend to immediately eat the first available COM port on boot rendering it unusable to anything else.

View solution in original post

0 Likes
Reply
New Contributor II

Hi KyTr,

Thanks for the link to the information on the NI site - I'm back in the lab tomorrow as I mentioned in the other thread so will check this out.

Hopefully it will lead me to the culprit.  Things have been more stable recently - I'm now thinking that it might be the Bootloader Host program that is hanging on to the port.  I have been making sure that the terminal emulator uses the same port each time after boot and the Bootloader Host never uses this port and it seems to stay functional.  I will try mixing and matching port usage again to try and recreate the problem and then maybe the NI software will confirm this.

I'll let you know.

Many thanks

0 Likes
Reply