Getting this message part way through boot loading PSoC5 with PC Bootloader Host - error message below. UART RX and TX buffers set to 64bytes as recommended and tried range of baud rates from 9600 - 115200 but still fails after a few seconds. We use the USB bootloader all the time but this is the first time we've needed to use UART/RS232. We're using a MAX3221 level shifter with the PSoC to get RS232 levels and a USB to RS232 "dongle" from the PC. Tried different USB dongles. Checked the RX and TX on a scope and they look OK.
Any other ideas?
Could you please attach you project. This would help us to recreate the issue at our end.
As per my understanding you are bootloading using the UART protocol in your project. You are then using the UART to USB converter dongle to connect to the PC Bootloader Host? Please feel free to correct me if my understanding is not correct.
Sorry for the delay in replying.
Yes, we are using the UART Bootloader. We are doing this using RS232 transport with a USB-RS232 adapter/dongle at the PC Host end and we have a MAX3221 level shifter from RS232 to TTL on our target design.
We have tried a few other things since my first post. We have made a very small bootloadable project (.cyacd file 5kB versus 55kB for the "real" project as it stands) and tried using this with both our target board and our CY8kit-050 Dev Kit which has a RS232 level shifter on board and this seems to work pretty reliably on both with the just an occasional programming failure. So it seems likely that it is due to the program size. The RX/TX buffer size used in the Bootloader UART for this was 256kB which we thought was huge versus the 64kB recommended in the AN68272 UART Bootloader reference document.
After @BiBi 's recommendation to try 1024kB we'll now give this a shot this afternoon and see how it goes.
I have attached the project as requested. It is still a work in progress as a partial port from a PIC project so please excuse the "mess" - once we get past this issue we'll get it all tidied up:-) I have also attached the current Bootloader project which is used the the "bootloadable" component in the project.
Hopefully there is some clue in there that you can find
Let me know if you need any more information.
Good to hear you are making progress.
I checked my 5LP Bootloader UART buffer sizes, 64 bytes each, 57600 bps. I use Bootloader UART config default parameters, only changed the data rate. My Bootloadable file is 24kbytes in FLASH. No errors/faults when bootloading. I use Kitprog in UART bridge mode. Essentially, a USB-UART dongle.
So, as you found, it can be done. The question is, why are you seeing errors?
If you originally programmed the target with Kitprog or Miniprog using USB-SWD, this means you converted the "normal" application to a bootloadable type. I have seen problems with this conversion and could not figure them out. I had to simply copy everything from the 'normal' project into a new bootloadable project that I pre-configured as bootloadable and then it bootloaded properly.
Are you using a custom Bootloader, or Cypress supplied Bootloader?
You type faster than me. So, my question has been answered.
Thanks for trying this. Just realised that I don't think I've mentioned the target device is a CY8C5868AXI-LP035.
During development so far we have had the bootloadable component in the project but disabled so we can debug more flexibly. With the bootloadable component enabled as we haven't been able to successfully boot load it yet we're programming via the target using a Miniprog 4. This project has been developed from the ground up as UART bootloadable application - we haven't tried a USB boot loading solution as it isn't appropriate for the end product.
Where do we pre-configure the project as bootloadable? I thought that the need for this disappeared with the introduction of Creator V3 or V4 (can't remember which) and later. I started a new project and couldn't see any option - have we missed something? Maybe this is the key?
We have been using the supplied PSoC Bootloader Host application on this project with UART defaults except 57600 baud as you did.
Your memory is better than mine. Yes, Creator 3.1 and earlier had a Build Setting to flip between 'normal' and 'bootloadable'. It's now done by a Disable checkbox in the Bootloadable component configuration Built-in tab. Sorry for my mis-direction. I'm supporting builds in 3.1 and 4.2, I sometimes forget what's where.
That said, I wonder if you're seeing the same issue I had when changing a not-bootloadable project to a bootloadable project. My solution was to manually copy/paste all the code into a new project. I also manually copied all the schematic, minus the bootloadable component, into the new project. I then added a new bootloadable component to the new project and configured the Dependencies. Build and cross your fingers.
I know there is a method to copy a project into another project, as a short-cut. I've never gotten this method to work properly. It's just as easy to copy/paste manually from scratch. It's a bit tedious, window-by-window, but it always works! File-by-file copies simply pick up all the bugs.
BTW, there's a note somewhere that mentions, whenever you re-build the Bootloader, you need to Clean and Build the Bootloadable. Maybe you did this when testing different baud rates? Something to check.
Sounds like we might need to give the "cut and paste" new project a go if all else fails.
I will try the "Clean and Build" first though - good suggestion. I was reloading the updated bootloader hex file into the bootloadable component each time we changed the buffer size before rebuilding (not clean and build though) but maybe it didn't rebuild the bootloader files as the filename wasn't changed .... maybe that is a factor as well!
I'll try it and feed back.
Tried the Clean and Build with 1024byte buffers in the Bootloader but it still crashes after variable times boot loading to the target board. I'm working from home without the DevKit today but hope to try the same using the CY8Kit-050 as a target tomorrow to see if it is potentially some issue with our target PCB.
Let you know how it goes.
Rats, another suggestion down the tubes. I guess we can cross that off the list of culprits.
I don't have Creator 4.4 installed. Creator 4.2 won't open your files.
Aside from using Kitprog in USB-UART bridge mode, I created another USB-UART dongle with KIT-059. It too was able to bootload my bootloadable into another KIT-059 target using PSoC Creator 3.1 and 4.2.
That said, it's PSoC Creator 4.4 Bootloader Host that's complaining about the invalid packet length. Maybe we're looking in the wrong places. I wonder if the error is in direction from Host-to-Target, or from Target-towards-Host? Packet length is calculated by lower layer protocol for sending/receiving packets.
Can you compile/build an example project, maybe the Blinky LED, and include a big text file to the project, no other code. Let's see if that can be bootloaded without error multiple times. If successful, it says there's something bizarre about the compile/build process for DLX project.
A few thoughts on UART RS232 connection.
Aside from signals TX and RX, have you connected Ground? It's a common misunderstanding that Ground is not needed, but it is.
Looking at MAX3221 chip, have you measured voltages at the pins FORCEON, FORCEOFFb, SHDNb, ENb, and un-used transmitters, to make sure they are in the right state? According to datasheet, these must be driven, not allowed to float. There's no internal pull-up/pull-down resistors on these pins.
You could monitor MAX3221 signal INVALIDb in case the USB-UART dongle is doing something unexpected with its TX signal. To do this, the un-used RX inputs can be left floating. See datasheet for clarification.
BTW, which 5LP GPIO pins are being used for UART TX and RX?
Apologies for the delayed reply - a lot going on around here although this problem is becoming a hot potato as we need to ship a couple of pre-production units which are running this project in the next few days so we need to be able to boot load in case our customer finds any bugs or needs a few "tweaks".
One of those things where you have on the project plan "Implement the bootloader, 1 hour" mainly because it is normally so easy with the PSoC and we thought the UART bootloader would be relatively straight forward compared to the USB method we always used before. Doh!
Anyway, RE the NMAX3221 all of the lines mentioned are tied high or low as required. We don't need any low power modes so it is just set to be on all of the time. We are using the same port to send commands to the target for configuration and this has worked reliably since the start. We don't monitor the INVALID line - probably should have connected this to a spare pin in hindsight. We can try and look at this during a transmission with a 'scope. We're using a single RX/TX device so no spare lines.
Ground is connected - this was one of the first things that we checked in case it had been missed.
Pins used for the UART are 12_2 (RX) and 12_3 (TX).
We have tried using the bootloader host applications from Creator V4.2, 4.3 and 4.4 and no noticeable difference and retried using both our target board and the CY8Kit-050 via its on board RS232 level shifter.
Regarding your suggestion about creating a "dummy" large file with a block of text in it, what's the easiest way to do this - won't the compiler just optimise it out? If you let me know we can try this today.
Thanks again for all of your help with this - very much appreciated:-)
Do you have a logic analyzer you would be able to use to snoop the serial traffic? Might help to see exactly what packets are being exchanged when the error occurs. It could be something like an extra byte sneaking in and the packet length then not matching the expected value.
Another thing to check if you are using a USB-Serial adapter is the buffer settings in windows device manager:
As far as including a large block of data in the firmware, if you declare it as volatile the compiler shouldn't optimize it out..
Thanks for the suggestions and sorry for the delayed reply. I've been out for a few days over Christmas but will be back in the lab tomorrow.
I did try playing with the FiFo buffer sizes before Christmas but it didn't seem to change the performance. I didn't try turning off the FiFo buffers s o will give that a try as well.
We have a basic (i.e. cheap!) logic analyser so I could give this a try and see if it shows anything up. Not sure how sophisticated the software is at decoding UART data - one way to find out! I'll let you know how it goes.
I've attached a dummy tex file. Around 53kBytes of constants.
I made it by taking a binary file, opening it in a HEX editor and saving as text. Then I used WORDPAD to format, copy/paste the necessary format.
Also, in main.c, I $included the text file and used a loop to read some bytes from the file. This prevented compiler from optimizing it out. I didn't try declaring as volatile as KyTr suggested.
You can also capture the serial data using a second PC, Hyperterminal, Putty, TeraTerm, etc. You'll only be able to log one side of the transaction at a time (unless you have 2 serial ports). Since the fault eventually causes the transfer to halt, you only have to look at the last few packets being transferred for diagnosis.
Thanks for the suggestions and the files - sorry for the delayed reply. I've been out for a few days over Christmas but will be back in the lab tomorrow when I'll give them a try. I'll also set up a "sniffing" arrangement with a second listening port in parallel as you suggested to see if there are any patterns in the message stream when it fails.
This is now getting more urgent as we're due to ship a couple of test systems to our first customer for the new design early next week (should have been before Christmas) and it is essential that we can boot load so we can address any issues/suggestions that they have on site without having to return the units to us.
I'll let you know how the test code goes.
One thing I forgot to mention is that we have tried the Bootloader Host from Creator V4.2, V4.3 and V4.4 and we get the same result each time. I haven't gone back any further - not sure if the Bootloader Host shipped with Creator V3.x versions. Can't remember!
No problem with delays. Everyone needs a break.
And now for a long shot. Here's 5LP UART Bootloader from Creator 3.1 files. It's invoked from a switch press attached to GPIO P2.2. You can change whatever you need to invoke the download from UART command (or whatever mechanism you need). I've used this successfully for several years now.
And, attached a 5LP Bootloadable with big text file (53kbytes).
You'll need to edit the UART GPIO ports for Bootloader file since I use P12.6 (RX) and P12.7 (TX) from KIT-059. Don't forget to change the Bootloadable Dependencies to point to this Bootloader.
Oh, and target will blink P2.1 if you connect an LED in Bootloadable.
I tested both files on KIT-059. Downloads worked 7 times in a row without issues. And yeah, it took a while at 57600. I think it was 3 minutes.
Try to compile/build the files without updating components, just in case it turns out there's a bug in the newer components of Creator 4.
Good luck. Let us know how it goes.
You'll need to change 5LP processor to your target processor/package.
Sorry, hadn't realised/noticed that the forum "upgrade" was taking place this week so couldn't reply for a couple of days.
Thanks for the two projects - I have been playing with them, more below.
Anyway, have done quite a bit since last time trying many permutations and combinations of Creator versions, component versions etc etc. I think I know more now but we still don't have a solution.
I built the bootloader/bootloadable projects initially using Creator 4.4 but it wouldn't build because of the "old" components. So I installed Creator 3.1 and built and tested the apps and the Bootloader Host (V3.1) loaded without a problem Tried also with Bootloader Host (V4.4) and this was OK as well so looks like it isn't a Bootloader Host version issue.
I also opened your projects in Creator 4.3 and updated the components to the latest versions (cy-boot 4.2 and Bootloader/Bootloadable 1.3) rebuilt and tested and it worked on both our DevKit and our Target board.
Anyway, before I realised you could "roll back" the components even in Creator 4.4, as I mentioned above, I spent a lot of time on trying various mixes of settings (component versions, baud rates, buffer sizes, different USB-RS232 devices, etc) but without learning much. After discovering "roll back" I then tried building our project in Creator 4.4 but rolling back to the relevant Creator 3.1 components (cy-boot 4.2 and Bootloader/Bootloadable 1.3). Still get the packet length error.
Your test program bootloads OK onto our hardware and the DevKit with the latest Bootloader/Bootloadable components.
STOP PRESS - I was typing this whilst trying some more ideas. I tried using the Bootloader I built from your test project (with mods to match our UART IO, LED, etc) in our application and it now works. I can't see any differences between the set up of the test software versus our original Bootloader app but something is obviously not right. Maybe it was because we originally built the test project in Creator 3.1 and then upgraded to the later components and built it in Creator 4.3. Maybe the problem was in Creator 4.4 as I stopped using that as well. We have a lot of test results (no time to type it all out right now) which we can analyse later.
Stepping back, the common factor is the our UART Bootloader project. We'll have to do some more digging to try and understand exactly what the problem is ... but after we finish off the code in the main project as we've lost several days trying to figure this out and we need to deliver the prototypes to our customer.
Many thanks for your ongoing assistance - very much appreciated. Hopefully we can find out the cause afterwards and then determine how it happened and if there is an issue with Creator or one of the components or something else. Be useful to know in case it comes back again!
We need to get our heads down for the next few days .... and try and finish our development by the weekend:-)
When you say, "we use the USB bootloader all the time", were you using Kitprog or Miniprog in UART bridge mode to perform this programming? I want to understand your successful setup for programming the target 5LP.
The issue of Packet Length Invalid almost always appears when RX/TX buffer size is not set to at least 64 bytes.
Can you try increasing the buffer sizes to 1024 bytes.
A good reference document is AN68272 UART Bootloader.
And, Getting Started Guide AN79953 (yes I know, it's for a PSoC 4) has great details on building a Bootloader, and configuring the Bootloadable to use it. The methods apply equally to the 5LP.
And, the Prototyping Kit Guide for KIT-049 has good examples of bootloader/bootloadables.
For our USB Bootloader we have our own PC Host based on the C# Bootloader application that used to be available (but then disappeared from what I remember). This works really reliably even for our largest and most complex projects.
We were up to 256kB buffer size already when we first posted which we thought was huge but have now tried 1024kB as suggested but we still haven't been able to complete a boot load. It seems to get a little further. I have no idea what the maximum size that we should go to would be ... 1024kB seems pretty massive and if that can't cope it would seem that there must surely be something else going on. We're using the Comms with no flow control as suggested in the App Note - we have many apps using serial comms and never have flow control or problems there. We don't really want to use flow control as all of our connector pinouts for the new design have been committed without any facility for any RS232 control lines. BY the way, we have tried the larger buffer with our larger cyacd file on both our target board and the CY8Kit-050 via its on board RS232 level shifter and in each case it fails.
I should add that it fails after different times each time - from a couple of hundred mS to 10+ seconds so it is not consistent.
Any thoughts on how far we can sensibly go on the buffer size? We have previously tried reducing the baud rate (at some of the smaller buffer sizes that we tried but this seemed to make no difference. Maybe we should try this in combination with the larger buffers.
Any other inspiration would be appreciated.
Are the buffers really 256kB?
It should be 256 bytes (or which-ever size in bytes), not K bytes. Maybe you wish it had 256kB! Would make many things easier.