- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All
Our company is already using the PSoC 4 BLE with bootloader and bootloadable application updatable using UART SCB, no issues works extremely well.
The attached PSoC 4 project is applicable for the below and runs on a kit-042 with the UART debug sent to a separate kit-044.
The project uses I2C for the bootloading process and using a UART for debug which has some unexpected behaviour only after a cold start.
After the project is programmed, no cold start, the operation is as expected, the bootloader then bootloadable are executed successfully.
Upon disconnecting the USB and board to board UART tx and rx lines from the kit-044 (these lines parasitically power the kit-042) then reconnecting, the code executes sending "Boot St" then the PSoC reboots. This operation occurs continuously. Cycling the power has no effect, however downloading the project to the kit-042 again fixes the issue until a cold start is performed once again.
/* Enable global interrupts. */
CyGlobalIntEnable;
/* Delay is needed here for PsoC reboots*/
//CyDelay(1);
/* Start UART*/
UART2_Start();
UART2_PutString("Boot Start\r\n");
To resolve the issue we have tried reading the UART status, waiting until the UART buffer is empty, not enabling global interrupts, delaying the watchdog etc.. without success. We did find that was adding a 1ms delay after the interrupt enable appears to resolve the issue for the hardware/software combination detailed above. That is, on any cold start the operation is the same as a warm start.
Does anyone have any thoughts on this cold start issue or see an obvious error we have overlooked?
Thanks Kindly
Greg
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reviewed your project. The issue could be due to XRES happening during a cold boot, while the the function Bootloader_Exit(0) writes to flash (metadata row) setting active application flag. If power goes off during this step, the bootloadable application checksum will be cleared. Application is treated as invalid and will not be launched. Adding a delay would have helped because it give some time for the reset happen before getting to Bootloader_Exit().
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi SmartPSoC
Thank you for the reply.
I have tested the XRES possibility and can see no spikes or dips with the reset line, this looks solid on cold boot. The attached image shows CH1 - XRES at the BLE device, CH2 - 5V rail and CH3 - 3V3 rail. Initially the KIT-042 is unplugged then a short time later the USB power is reapplied.
Taking testing one step further, only the TX and GND line from the KIT-042 to the KIT-044 board are connected. Even after inserting a 10K series resistor with the TX line, without the 1ms delay, and pressing only the RESET button on the KIT-042 the same unexpected behaviour is seen.
Can think of any other possible issues or testing that should be considered?
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you ever measure the noise on your supply rails? From the scope picture above it looks as if you have got nearly 0.8V p-p on your 3.3V rail which would be quite too much.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob
Thanks for the reply. In answer to your question, I was using a long acquisition mode on the scope, below is a real time capture where the delta V is much more reasonable.
Looking at the rails there was some noise.
After suspecting a noise issue I dropped the computers Toshiba Dynalock port replicator from the usb and the setup is running with the need for the delay in the bootloadable project. Issue is now preventable however unsure as to the root cause.
Appreciate the support, thank you all!