chipKIT® Development Platform

Inspired by Arduino™

Slow startup?

Created Wed, 13 Jul 2011 11:05:32 +0000 by ron.dunn

ron.dunn

Wed, 13 Jul 2011 11:05:32 +0000

I've just ported my application from Arduino, and have to say that it was an amazingly smooth process ... it took less than a day, and most of that time was getting Code::Blocks set up correctly with the Pic32 environment so I could avoid that brain-damaged Arduino "IDE".

My only problem is with the serial LCD panel I'm using for text output. It isn't initializing reliably on power-up.

One thing I've noticed is that the Max32 seems much slower to start than the Mega2560. That MIGHT be causing problems for the LCD, but I'm still trying to debug the problem.

Has anyone else noticed a slow start? If so, is there any way around it?

svofski

Wed, 13 Jul 2011 15:10:18 +0000

Not the slow start but it appears to waste more time than necessary in the bootloader. You can see it when you upload the code: first it blinks RX/TX for some 5 seconds, as if trying to negotiate something without getting carried away by the immediacy of instant success, then finally something latches on and the actual upload starts: RX/TX are half-lit for 0.5-1 second. I'm pretty sure that the initial lazy blinky phase can be optimized away almost completely, but it could be a problem of the bootloader which you can't reprogram without a real programmer and a real brain. I have neither, it's just a speculation.

(Yeah, and I'm using it arudinoless too. Hello, fellow sentient being!)

ron.dunn

Wed, 13 Jul 2011 23:51:25 +0000

Agree, svoski, that's gripe #2.

I've got verbose mode on for AVRDUDE to look into this, but the LCD problem is higher priority at the moment.

I'm using the SERLCD 4x20 serial LCD from SparkFun. Now that I've got pins to spare I might just look for an alternative (non-serial) device and see if that gets me past the problem.

Being positive, though, I am definitely impressed by the work that has been done to date. Given its limited maturity, I didn't expect the MAX32 to work anywhere near as well as it has.

svofski

Thu, 14 Jul 2011 10:31:14 +0000

Being positive, though, I am definitely impressed by the work that has been done to date. Given its limited maturity, I didn't expect the MAX32 to work anywhere near as well as it has.

May I join you in this. If I'm grouchy it's because I really like the board and really want it to behave when it doesn't. Great job, designers and programmers!

ron.dunn

Thu, 14 Jul 2011 11:32:03 +0000

OK, I think I've got to the bottom of the slow upload.

Here are the command line options for AVRDUDE:

http://www.nongnu.org/avrdude/user-manual/avrdude_4.html

Add the -V option to your AVRDUDE call and you'll disable the verification read, which is the long, steady cycle in the latter half of the upload process.

As an example, here is my command line:

-CC:\chipkit\hardware\tools\avr\etc\avrdude.conf -F -u -q -p pic32 -c stk500v2 -P\.\COM4 -b115200 -V -D -Uflash:w:pic32$(PROJECT_NAME).hex

That halved my upload time.

Unfortunately it has done nothing to improve the terribly slow reset/boot time. Watching that slowly flashing light 13 times on every start seems to take forever. I'm hoping one of the development team will jump in with some suggestions.

rtestardi

Fri, 15 Jul 2011 04:00:57 +0000

Hi Ron,

Unfortunately it has done nothing to improve the terribly slow reset/boot time. Watching that slowly flashing light 13 times on every start seems to take forever. I'm hoping one of the development team will jump in with some suggestions.

On reset, the bootloader (see: https://github.com/chipKIT32/pic32-Arduino-Bootloader ) takes control of the mcu. It then waits for 4-5 seconds monitoring the serial port to see if there is any Stk500v2 protocol activity. If there is not, it transfers control to the previously loaded application.

This is the model used on boards that auto-reset (using an FTDI chip) and don't have a PRG (enter bootloader) switch... We've done a bit differently for native USB boards (that don't have an FTDI chip and have a PRG switch -- see: https://github.com/rtestardi/PIC32-CDC-ACM-Stk500v2-Bootloader ), which allows them to take off almost immediately to the application on reset (if PRG is not pressed); on the down side, you have to manually press PRG and RESET every time you want to download a new application for these boards.

I think your best bet to change this is if you have a pickit3 or something, you can download the bootloader and you can change this line in pic32bootloader.c to make the wait shorter if you really want:

#define	MAX_TIME_COUNT	(F_CPU >> 1)

...

	while (!(U1STA & 1))
	{
		// wait for data
		count++;
		if (count > MAX_TIME_COUNT)
		{
			//*	jump to user program
			JumpToApp();
		}
	}
	return (U1RXREG);

ron.dunn

Fri, 15 Jul 2011 04:32:40 +0000

rtestardi, thank you for the comprehensive reply!

If I do modify the bootloader, can you think of anything I might regret? For example, are there enhancements planned that might require the functionality I'm about to turn off?

The reason I want to do this is because the slow startup is killing my serial LCD device (Sparkfun SerLCD). It is taking too long from the time it gets powered on until the time I start sending it data. If I manually connect power near the end of the bootloader cycle everything works fine, but obviously I can't do this in a live application.

The only circumstances in which I can see me using the serial port / FTDI interface is after the device has booted, whilst I'm developing code. Based on your design choice, though, I'm wondering if I've missed use cases that might come back to bite me later?

rtestardi

Fri, 15 Jul 2011 04:51:35 +0000

If you have a pickit3 you can always go back to the "official" bootloader... I don't know what bootloader changes are planned for the future, but I'm sure there will be some, so you'll want to track them (you can follow repositories on github).

I'm a bit baffled why the serial lcd should require you to talk to it within a certain time of power on -- I've never experienced that... What uart on the PIC32 are you using?

If I manually connect power near the end of the bootloader cycle everything works fine, but obviously I can't do this in a live application.

Could there be some other interference occurring that is getting the lcd into a bad state? My guess would be that is the real issue here, not the 4-5 second delay, but I suppose anything is possible... :-)

My guess is that either the ftdi chip or the bootloader itself is generating some uart traffic that you may need to hide from the lcd...

ron.dunn

Fri, 15 Jul 2011 05:14:14 +0000

I've tried Serial2 and Serial3 without success.

I didn't think to try Serial1 - it has a VDrive USB host - but I'll switch them around tonight and see if it makes any difference.

The LCD initialisation is the third thing that gets executed in the startup routine. I get the same problem with or without the pc (Serial) calls in place. Here's a snippet:

void setup() {

	// Initialise all pins.
	
	for (int i=0; i<54; ++i) {
		pinMode (i,INPUT);
		digitalWrite (i,HIGH);
		}

	// Initialise the pc interfaces.

	pc.begin (9600L);
	pc.println ("GRUNT - Gcode RUN Time - 1.00");

	// Set up the LCD display.

	lcd.Init (9600L);
	lcd.Backlight (40);
	lcd.Clear ();

That lcd class is just a wrapper around a HardwareSerial class with some extra functions. The Init() method is nothing more than a device.begin() and a brief delay().

I'm not sure how I could hide interference from the LCD ... I'm a software guy (well, database, really) and the electronics are something I'm learning as I go. Suggestions welcome :)

rtestardi

Fri, 15 Jul 2011 12:20:59 +0000

Hi,

The first thing that jumps out at me is this:

for (int i=0; i<54; ++i) {
      pinMode (i,INPUT);
      digitalWrite (i,HIGH);
      }

You're manipulating the pins that are also your UART(s), and you're doing digitalWrite on INPUT pins -- not sure what the effect of that could be, but I could envision ways that might result in UART noise...

However, I think the key for what we should be searching for is in what you said here:

If I manually connect power near the end of the bootloader cycle everything works fine, but obviously I can't do this in a live application.

That seems to imply that the bootloader (vs. your code) might be manipulating the UART pins and making noise, but I can't see how from the bootloader code.

Can you try a different experiment?

Disconnect the UART pins (not power pins) from the LCD and power on the whole system at once, and then connect the UART pins at the same time above (i.e., "near the end of the bootloader cycle").

If that solves the problem, then we know it's not power-on delay, but UART noise...

I assume there is nothing else in your circuit using those UART pins? And you are only using TXD/RXD (no hardware flow control)?

-- Rich

ron.dunn

Fri, 15 Jul 2011 23:26:02 +0000

I think we've confirmed that the problem is UART noise.

I'm only using a TX pin, this is a three-wire serial interface, no flow control. Inserting the TX wire AFTER applying power to the board reliably fixes the problem. It behaves the same regardless of whether Serial1, Serial2 or Serial3 is being used.

The noise must come right at the beginning of the power-up, I can plug the TX wire in as quickly as I like, or wait until the end of the boot process.

I commented out that pin initialization code, it made no difference to the problem.

Any thoughts on how to fix? If I was using Arduino I'd try the NewSoftSerial library, but I don't think that works on Max32. I did think about powering the LCD from an output pin so that I could control its power-up, but they're only 3.3V and the LCD requires 5V.

I'm a bit stumped :(

rtestardi

Sat, 16 Jul 2011 01:42:33 +0000

Can you try putting an external 10k ohm pull-up on the pin? The pin should default to digital input until it is actually configured. The pull-up will prevent the lcd from seeing any false start bits.

ron.dunn

Sat, 16 Jul 2011 05:29:01 +0000

A pull-up on the pin made no difference.

I'm thinking that my best option is to put this serial device to one side, and order an alternative LCD. I've got plenty of pins on the Mega32, I can afford to use a few more for a display.

rtestardi

Sat, 16 Jul 2011 12:03:28 +0000

Bummer...

It seems the bootloader has the ability to send diagnostics out UART 2 or 3 -- I wonder if that could be enabled...

Also, I think I goofed when I was identifying the bootloader reset timeout above -- I think it is actually here:

#if defined(_BOARD_DIGILENT_UNO_) || defined(_BOARD_DIGILENT_MEGA_)
	//*	boot_timeout is in 10 microsecond increments
	boot_timeout	=	4 * 100000;		//*	should be about 4 seconds
#else
	//*	longer timeout for boards without auto reset
	boot_timeout	=	10 * 100000;		//*	should be about 10 seconds
	#error foo
#endif

...
			while ((!(Serial_Available())) && (boot_state == 0))		// wait for data
			{
				delay_microSeconds(10);
				boot_timer++;
				if (boot_timer > boot_timeout)
				{
					boot_state	=	1; // (after ++ -> boot_state=2 bootloader timeout, jump to main 0x00000 )

rtestardi

Sat, 16 Jul 2011 18:22:54 +0000

Can you tell me what pin exactly you are using for your UART? I'll put a scope there and see if anything is happening on startup...

ron.dunn

Mon, 18 Jul 2011 23:24:17 +0000

I really appreciate the help you are giving me!

I don't have a preference for the pin to use for the LCD, other than it must be the TX pin for Serial1, Serial2 or Serial3. I've tried all three, and each one presents the same problem.

Let's go with Serial3 - it is the easiest pin to identify with my old man's eyesight :)

To be precise, I'm talking about pin TX3 / 14.

Ron.

rtestardi

Tue, 19 Jul 2011 13:01:34 +0000

Hi Ron,

Unfortunately, I see nothing on TX3 following a reset. However, a pull-up is definitely required -- the pin floats low by itself, which would be a false start bit (followed by a framing error)... With a pull-up, it stays high until programmed by the application. The "noise" you are seeing is definitely before the application runs (during the 4 second bootloader delay), so I am a bit perplexed... Are you powering the board on for real, or have you also tried just pressing the reset button? You can access the mclr* (reset*) line on JP5 (Max32), if you can route that to the serlcd as well...

-- Rich

ron.dunn

Tue, 19 Jul 2011 13:14:41 +0000

Hi Rich (at least I have a name for the "r" now!)

I'm definitely powering the board, by physically disconnecting the USB connection.

A reset using the button takes its result from the previous power-on situation. If I had waited before plugging in the LCD, so that it was properly initialised, a reset will continue to work successfully. If the LCD was showing garbage before the reset it will continue to show garbage after a reset.

Since I'm not claiming to be an electronics guy, let me validate that I'm using a pull-up resistor correctly. I've got each wire on the LCD connected to a separate column on a breadboard. The column with the red wire (5V) goes to the 5V power rail, the black wire (gnd) goes to the ground rail, and the blue wire column (device RX) is connected to TX3. To add a pull-up resistor, I connected a 10k resistor between the blue wire column and the 5V rail. Is that what you meant me to do?

I'm planning to look into the bootloader startup time. I've ordered a PICKIT 3, but it won't get here for a week or so. Speaking of PICKIT, it was a bloody nuisance to find that the Max32 doesn't have a connector, that I'll have to solder one myself. When you're on the wrong side of fifty with eyes that have been staring at CRTs for 30 years and nerves-of-Chinese-steel, that isn't a task with a guaranteed quality result sigh

Ron.

rtestardi

Tue, 19 Jul 2011 13:43:18 +0000

OK, this is good info... It sounds like the issue is definitely power-on, and not reset, so it's not related to the bootloader running... Your pull-up sounds right.

Am I to understand you have a 5V LCD connected to a 3.3V MCU? It should work, but often you'll want a level shifter like: http://www.sparkfun.com/products/8745

You have to be careful pulling 3.3V pins high to 5V (the analog-capable PIC32 pins are not 5V tolerant; though the digital-only PIC32 pins are), but in your case I believe you are fine.

Do you have the ability to power the serlcd on independent of the chipKIT? Can you power it up first, and then power on the chipKIT (with the TX3 line connected) as an experiment?

Speaking of PICKIT, it was a bloody nuisance to find that the Max32 doesn't have a connector, that I'll have to solder one myself.

You don't necessarily have to solder -- you can just push a male header (6-pin) into the underside of the board and it should stick thanks to the slightly offset pin holes... I actually leave the header in the pickit3. Just be sure to get pin 1 right.