On Power-Up bootloader jumps directly to he application [solved]

[vmsbarbosa]

Hi all,

I have an application with dsPIC33FJ128GP708A and it is working at 40 MHz(internal clock with PLL and tunning), UART2 for bootload, and data initialization support(crt0.s from C30).

I have ds30 loader working perfectly in my application. I defined 5 seconds delay in the firmware and when I reset the device it waits 5 seconds before jumping (if there is not a bootload command from the GUI), and it has this behaviour repeateadly.

Something strange happens when RX of UART2 is floating or pulldown to GND: on power-up it jumps directly to the application without waiting the 5 seconds. If RX is pulluped to VDD the behaviour gets normal: it waits 5 seconds for a bootload command from the GUI before jumping to the application.

Was it designed to work like this? Is it possible to disable this? A this moment it is a bit expensive to change the hardware of the application.

Kind regards,

Vitor

[vmsbarbosa]

I didn'nt have time yet to explore this on firmware, but bootloader start-up should be independent of the logic level input at RX. It shouldn't jump if a logic level "0" is present at RX on start-up or after a reset.

If this is important to the user and the user choose the hardware solution (the placement of a pullup resistor at RX), careful has to be taken with the pullup resistor value:
With a value very big, as 100K or more, associated with the capacity value of the pcb trace, the voltage don't have or may not have time enough to rise to a logic level "1" in a short time of a few ms, from power-up to the moment when RX is read by the first time. This effect is only present on power-up, but on a normal reset this is solved.
With a smaller value, 10K (on my board), the power-up problem was solved, as RC time contant is smaller. Capacity of the pcb traces depend on the pcb design and this value could not work on other designs.

This could not be important for the most users, as in general RX/TX lines are connected to a transceiver (RS232 or RS485 or...) and the output of this devices is a logic level "1" in the absence of communications (the start-bit on UART protocol is recognized as fall-down edge) but surprises could happen.

Although this, the bootloader is working perfectly in my application.

Thanks for this bootloader!

I will try to fix this on the firmware.

Vitor

[Mikael Gustavsson]

Thanks for the reports!

My guess is that the uart thinks it receives a byte. The PIC18 firmware has a feature to discard a few non hello bytes on startup. I think that should solve your problem. I'll add this feature to the next release.

In the meantime you can implement this yourself and update the bootloader. Let me know if you're interested in the bootloader upgrade procedure.

[vmsbarbosa]

Yes, my guess is that too about the UART.

I didn't look for the PIC18 bootload firmware but it is my intention as I have another application that uses a PIC18F6722, and possibly I will upgrade it with your bootlader as it downloads a program very fast.
Currently this 18F application has an adaptation of the Microchip AN485 bootloader.

I will try to see how you made it and adapt, although it is not my priority in this moment.

About the upgrade procedure , Yes, I'm interested in that too.

Regards,

Vitor

[Mikael Gustavsson]

I've added a new section in the manual that describe the upgrade procedure.
It's available on the homepage.