topic Re: LPC1343 startup issue in LPCXpresso IDE

LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:04 GMT

Content originally posted in LPCWare by BoyBoogaloo on Wed Aug 10 09:48:12 MST 2011
Hello,

I have a custom board with an embeddeed LPC1343. I have been programming it via USB, (pull PIO0_1 low, USB boot with PIO0_3 high, enumerate as MSC device to PC, etc.)

The USB also supplies 5V which is regulated to 3.3V to power the LPC1343 and the user code executes properly upon reset.

The problem comes when I switch to using a different power supply. When I start the board with an external 5V supply and no USB cable plugged in, the LPC1343 takes about 1 minute before it begins to execute the user code. If I plug in the USB cable during this delay time, the user code starts execution immediately. Oddly enough, this procedure still works when only the DATA lines of the USB cable are connected during the start-up delay (D+ and D-). I can't understand the reason for this.

Help!

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:05 GMT

Content originally posted in LPCWare by kendwyer on Wed Aug 10 17:40:28 MST 2011
Very strange....is it related to the following, see LPC1300 UM, 19.2.1

1 In the user code, the memory location must be initialized as follows to create a
work-around for this issue:
*((unit32_t *)(0x1000 0054)) = 0x0;

2. If the USB ISP mode is entered on power-up (see Section 19.3), the memory is not
initialized, and no user code is executed which could write to this memory location.
Therefore the device times out when first connected to the Windows operating
system, and the MSD disk only appears after a time-out and retry, which takes 45 sec
or longer. A work-around for the time-out issue is not available.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:05 GMT

Content originally posted in LPCWare by Rob65 on Wed Aug 10 22:46:33 MST 2011
Boy,

When ISP mode is entered, it will stay there forever waiting for a connection.
So that already answers the question if you still have P0_1 pulled low (no).

When P0_1 is not pulled low during reset, the lpc1343 immediately starts executing user code.
Not knowing what your hardware or software looks like it is kind of difficult to give a solution.

Does your code use the USB drivers from ROM? In that case, use the workaround as given by Ken (add[I] *((uint32_t *)(0x1000 0054)) = 0x0;[/I]). It could be a solution to your problem.

Did you also test this with something basic like the Blinky example code? This surely sound like a problem with your user application or some kind of a powering/reset issue - although I am unable to explain why connecting the datalines should help in that case.

Rob

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:06 GMT

Content originally posted in LPCWare by ktownsend on Thu Aug 11 01:50:29 MST 2011
Indeed, it would be easier to offer some help if you could post a partial schematic showing USB, power and how you have the ISP/Bootloader pin connected. If you set a breakpoint at the start of main, does it take 1s to arrive at main() before any user code is executed? Is it possible the delay is caused a bit later in the user code during initialisation, such as waiting for USB when it isn't connected, etc.? You may have already checked this, but setting a breakpoint before any meaningful user code is executed would at least help narrow down where the delay is occuring.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:06 GMT

Content originally posted in LPCWare by BoyBoogaloo on Thu Aug 11 09:46:11 MST 2011
@kendwyer

That is a possibility that I am experiencing the device time out going into USB ISP mode. (In fact, I do see that delay when I go to load the program via USB) However, I am getting this delay when going to user code, which I don't think is right.

@Rob65

I'm not using the USB ROM drivers, so that should not affect my program. I've tried running simple "blinky" type code, but my programs doesn't even begin to execute until after the delay.

@KTownsend

The user code does not execute at all until after the delay. I'm including a schematic that shows my USB circuit. It does not show my external power supply with 3.3V regulator, but I have checked the external power and the output is fine. On the USB connector (on the left) the U_RESET and U_ISP lines are connected to external switches which ground those inputs when pressed.

[ATTACH]529[/ATTACH]

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:07 GMT

Content originally posted in LPCWare by Rob65 on Fri Aug 12 00:44:53 MST 2011
My first thought is that the supervisor circuit is playing a joke on you.
Not knowing the exact type of the reset generator (U2) and the missing 5V/3V3 converter leaves me a bit in the dark but I am guessing that depending on the power supply it takes too long for the 3v3 to reach a level at which U2 releases the reset line.

Carefully check your 3v3 level and the reset line when powering your board.

Rob

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:08 GMT

Content originally posted in LPCWare by Polux rsv on Fri Aug 12 01:18:42 MST 2011
Unless the Reset pin of LPC1343 has an internal pull-up, there is no external pull-up. I would try puting an external 10k to check if it helps.

Angelo

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:08 GMT

Content originally posted in LPCWare by Rob65 on Fri Aug 12 01:42:57 MST 2011
The chip does have a pull up, but it's just a weak pull up so this may not be enough when external components with OC/OD outputs are used.
If U2 has an open collector ouput you should add a pull up, but I would still suggest to first try without this chip to detect any power/reset problems.

I've seen funny things with these type of chips where it can take a relatively long time before the reset line is released when the power (reference) voltage rises to slow.

There is a power on reset circuit in the chip so there is no need to include an external reset for the lpc1343 to behave correctly. But it still may be very useful since the lpc1343 works from voltages as low as 2.0V.

Rob

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:09 GMT

Content originally posted in LPCWare by ktownsend on Fri Aug 12 06:36:33 MST 2011

Quote: Rob65
The chip does have a pull up, but it's just a weak pull up so this may not be enough when external components with OC/OD outputs are used.
If U2 has an open collector ouput you should add a pull up, but I would still suggest to first try without this chip to detect any power/reset problems.

I initially dropped the 10K pullup on reset myself when I started with the 1114/1343 thinking the internal pullup is enough, but remember one situation where I had to add it back in and have been doing so since. Alas ... the exact reason escapes me now :( (I think it was a problem with either waking up from deep sleep or the bootloader after a SW-based reset). Despite the (very weak) internal pullup I would strongly recommend an external 10K pullup on the line.

I'd try pulling U2 off as well and see if that helps since it seems like a likely culprit to me.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:10 GMT

Content originally posted in LPCWare by wdawson61 on Sun Aug 14 06:26:47 MST 2011
On a side note, I notice from your schematic that your "USB_CONNECT) signal will never pull D+ lower than 3.3v - ~.7v = 2.6v (give or take based on the transistor's hFE) Is that low enough to force a bus enumeration?

-Wade

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:10 GMT

Content originally posted in LPCWare by BPC on Thu Oct 27 11:26:22 MST 2011
I am able to successfully communicate (send commands, receive data) with the LPC1343 using a modified version of the CDC example. However, this only works when using the debugger. When I try to just plug in my device to Windows, it shows up as a USB Mass Storage Device (not what I want). When using the debugger, it shows up as a VCOM port (what I want).

I did a quick experiment and found that after the device boots up as a Mass Storage Device, I can press the reset button and it will change to a VCOM port. Is there any way I can have the device show up as a VCOM without having to press restart or use the debugger?

Thank for the help.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:11 GMT

Content originally posted in LPCWare by Ex-Zero on Thu Oct 27 13:09:00 MST 2011

Quote: BPC
I did a quick experiment and found that after the device boots up as a Mass Storage Device...

Are you aware that MSC is a part of LPC1343 bootloader :eek:

I would strongly suggest to check your PIO0_1 (and it's pullup) :)

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:11 GMT

Content originally posted in LPCWare by BPC on Thu Oct 27 14:33:09 MST 2011
Thanks Zero. Worked immediately.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:12 GMT

Content originally posted in LPCWare by BPC on Mon Oct 31 16:59:58 MST 2011
What is the best way to collect serial buffer incoming data and wait until a '\r' is received? I noticed that using the below code, the incoming data (say 10 bytes), comes in small groups, first1 byte, then 3 bytes, then 2 bytes, etc. One I receive a '\r', I need to act upon it, but I need to retain the integrity of the entire incoming data string.

if (numAvailByte > 0)
{
numBytesToRead = numAvailByte > 32 ? 32 : numAvailByte;
numBytesRead = CDC_RdOutBuf (&serBuf[0], &numBytesToRead);
...
}

I am able to work around this by changing to [if (numAvailByte > 9)], however, some of the incoming commands are 3 bytes, some 8 bytes, and some 10 bytes, so this doesn't work for all cases. The one saving grave is that they all have a '\r' at the end of each command.

Any help would be much appreciated. Thanks.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:13 GMT

Content originally posted in LPCWare by Ex-Zero on Mon Oct 31 17:15:20 MST 2011
I usually write incoming buffer bytes into a new command buffer until \r is detected.
After interpreting and executing this command I reset command buffer byte counter and start to read a new command :)

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:13 GMT

Content originally posted in LPCWare by BPC on Wed Nov 09 09:45:23 MST 2011
Hi Zero,

Thank you again for both of your replies. They were very helpful. My firmware is coming along quite well now, but I am running into a code size issue for my LPC1343. I am a few hundred bytes away from the 32kB limit.

The code that I have written isn't anything too crazy (~1000 lines), but I'm hoping that I can reduce my code size by removing some of my unused #includes or by optimizing some of these header files.

I also noticed that when I added my first sprintf, my code size immediately increased by about 10kB.

Any advise would be much appreciated.

Thanks.

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:14 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Nov 09 09:57:55 MST 2011

Quote: BPC
I also noticed that when I added my first sprintf, my code size immediately increased by about 10kB.

Any advise would be much appreciated.

Advice: Don't use sprintf :)

If it's possible use itoa :eek:

http://support.code-red-tech.com/CodeRedWiki/redlib_v2_notes?highlight=%28itoa%29

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:14 GMT

Content originally posted in LPCWare by BPC on Fri Nov 11 10:51:27 MST 2011
Zero,

I would like to store about 10 "calibration" or zeroing values (for an ADC) in flash memory so they will be retained during power cycling.

Is there an easy way to store variables in flash?

Thanks,

Brian

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:15 GMT

Content originally posted in LPCWare by BPC on Mon Nov 14 10:32:15 MST 2011
What is the best way to convert a float to a string (for serial buffer) without using sprintf?

Re: LPC1343 startup issue

lpcware — Wed, 15 Jun 2016 22:23:16 GMT

Content originally posted in LPCWare by Ex-Zero on Mon Nov 14 10:35:54 MST 2011
#1 Cast it from float to int :rolleyes:
#2 Use itoa

or google for ftoa

ftoa (x, str, prec, format)
float x;
char *str;
{
/* converts a floating point number to an ascii string */
/* x is stored into str, which should be at least 30 chars long */
int ie, i, k, ndig, fstyle;
double y;
if (nargs() != 7)
  IEHzap("ftoa  ");
ndig = ( prec<=0) ? 7 : (prec > 22 ? 23 : prec+1);
if  (format == 'f' || format == 'F')
 fstyle = 1;
else
 fstyle = 0;
/* print in e format unless last arg is 'f' */
ie = 0;
/* if x negative, write minus and reverse */
if ( x < 0)
  {
  *str++ = '-';
  x = -x;
  }

/* put x in range 1 <= x < 10 */
if (x > 0.0) while (x < 1.0)
  {
  x =* 10.0;
  ie--;
  }
while (x >= 10.0)
  {
  x = x/10.0;
  ie++;
  }

/* in f format, number of digits is related to size */
if (fstyle) ndig =+ ie;

/* round. x is between 1 and 10 and ndig will be printed to
   right of decimal point so rounding is ... */
for (y = i = 1; i < ndig; i++)
  y = y/10.;
x =+ y/2.;
if (x >= 10.0) {x = 1.0; ie++;} /* repair rounding disasters */
/* now loop.  put out a digit (obtain by multiplying by
  10, truncating, subtracting) until enough digits out */
/* if fstyle, and leading zeros, they go out special */
if (fstyle && ie<0)
  {
  *str++ = '0'; *str++ = '.';
  if (ndig < 0) ie = ie-ndig; /* limit zeros if underflow */
  for (i = -1; i > ie; i--)
    *str++ = '0';
  }
for (i=0; i < ndig; i++)
  {
  k = x;
  *str++ = k + '0';
  if (i == (fstyle ? ie : 0)) /* where is decimal point */
    *str++ = '.';
  x =- (y=k);
  x =* 10.0;
  }

/* now, in estyle,  put out exponent if not zero */
if (!fstyle && ie != 0)
  {
  *str++ = 'E';
  if (ie < 0)
    {
    ie = -ie;
    *str++ = '-';
    }
  for (k=100; k > ie; k =/10);
  for (; k > 0; k =/10)
       {
       *str++ = ie/k + '0';
       ie = ie%k;
       }
  }
*str = '\0';
return;