LPC1343 startup issue

[lpcware]

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!

[lpcware]

Content originally posted in LPCWare by BPC on Thu Dec 01 16:36:52 MST 2011
I was able to implement a similar version of the I2C project that Rob65 posted.  For a little bit of a background, I have 3 eeproms that I am ACK polling at a rate of about 10Hz.  To test the ACK polling, I have been hot plugging the different eeproms and the system has been working fine, showing which eeproms are available and which are not via VCOM.

However...

If I disconnect just GND from an eeprom (simulating a realistic hot plug), the I2CEngine function hangs because 'while(I2CMasterState < 0x100);' never returns as the value of I2CMasterState = I2CSTATE_PENDING = 0x001.

To work around this I added a 10ms timeout to the 'while(I2CMasterState < 0x100);' portion of I2CEngine and it started working again.

I then started decreasing my timeout down to 1ms, and then all I2C stopped working.  I can increase the timeout and everything "works" but it just isn't a robust system. Any advice on this situation?  I really don't like having these fixed timeout delays.  Feels like walking on thin ice.

[lpcware]

Content originally posted in LPCWare by BPC on Thu Dec 01 11:32:27 MST 2011
Ok very strange.  Turns out that my first function just below all of my #includes, #defines, and global variables was unused.  I comment out the function, and local variable viewing / debugging is working again.

I thought I was going crazy, so I uncomment the function to check and local variable viewing / debugging no longer works.

Finally, I romment out the function again and it's working.  Strange.

[lpcware]

Content originally posted in LPCWare by BPC on Thu Dec 01 11:10:21 MST 2011
I just tried removing --gc-sections and did a rebuild.  Then my code went from about 26K to about 39K and I'm now getting the overflow error message when I compile because it's over 32K.  :(

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Thu Dec 01 11:00:24 MST 2011
Did you try to remove linker option '--gc-sections' already ?

[lpcware]

Content originally posted in LPCWare by BPC on Thu Dec 01 10:36:34 MST 2011
After pausing my code, say at a breakpoint, the debugger (LPCXpresso Code Red) doesn't show any variable values unless they are global.

In "Expressions" all local variables show [COLOR=Red]<error(s)_during_the_evaluation>[COLOR=Black].[/COLOR][/COLOR]

Any help would be greatly appreciated.  I'm running blind now.

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Nov 29 23:46:04 MST 2011

---

Quote: BPC
Is there an easy way to change the "CRP DISABLED" name of the mass storage device after entering ISP mode? Or is this in the ROM?

---

It's in ROM, at least there is no defined way in the user manual to change the name.

I can't blame Brian for the uint32 and the space in the code.
Just went to the NXP website, searched for lpc1343 which got me to this page and downloaded the user manual from there.
It's "[B][COLOR=Red]Rev. 3 - 14 June 2011[/COLOR][/B]" with the errors ...

If you search for the IC in the "ICs quick find" you'll always end up with the old manual. The newer one you'll only find if you type in "lpc1343 user manual" in the general search field on top of the webpage.
To make it easier, here is the link to UM10375.pdf.
And that one still contains the error :eek:

Rob

[lpcware]

Content originally posted in LPCWare by BPC on Tue Nov 29 15:56:02 MST 2011
Is there an easy way to change the "CRP DISABLED" name of the mass storage device after entering ISP mode? Or is this in the ROM?

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Tue Nov 29 12:58:20 MST 2011
UM10375 LPC1311/13/42/43 User manual Rev. 4 &#8212; 28 September 2011

is suggesting to reset this part of On-chip RAM (0x10000050-0x10000180 USB Driver RAM), even if there are no problems without it (until now :rolleyes:) .

---

Quote:

21.2.1 Bootloader code version 5.2 notes
In bootloader version 5.2 (LPC134x parts), the mass storage device state machine uses
an uninitialized variable. This has two consequences:
1. In the user code, the memory location must be initialized as follows to create a
work-around for this issue:
*((uint32_t *)(0x10000054)) = 0x0;
2. If the USB ISP mode is entered on power-up (see Section 21.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.

---

[lpcware]

Content originally posted in LPCWare by BPC on Tue Nov 29 12:21:18 MST 2011
thanks...

Turned out to be my USB_CONNECT signal.  Realized that I have to do a soft disconnect by pulling USB_CONNECT high (which then stops pulling up USB D+ through a PNP). 

As for the  *((uint32_t *)(0x10000054)) = 0x0; line, it seems like the code works the same with and without it.  Is this true?

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Tue Nov 29 11:16:30 MST 2011

---

Quote: BPC
I tried adding  *((uint32_t *)(0x1000[COLOR=Red]SPACE[/COLOR]0054)) = 0x0; to my code, but the compiler doesn't like it.

---

I don't like it, too, We can't read it with SPACE :eek:
What did the compiler tell you?

[lpcware]

Content originally posted in LPCWare by BPC on Tue Nov 29 11:04:48 MST 2011
Rob,

Thanks for the reply.  Basically, I would like my board's firmware to have the option of being upgraded in 'the field' by running a simple update program.  Even though it's a 'real' product, there aren't any negative consequences should I/O have random values during reprogramming or reset.

I tried adding  *((uint32_t *)(0x1000 0054)) = 0x0; to my code, but the compiler doesn't like it.

I have P0.1 pulled high and P0.3 connected my my USB VBUS (so high).

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Nov 29 10:38:04 MST 2011
You might want to explain a bit on what you are exactly doing.

See section 19.4 in the lpc1343 user manual, there is a detailed explanation about P0.1 (ISP mode) and P0.3 (USB_ISP).

Just watch out when using these modes in 'real' products. All I/O is initialized with reset values. This may result in unwanted behaviour in your product.
I my system this means all power LEDs switch on during programming - but the system is not designed to be able to supply enough power for this ...

The " *((unit32_t *)(0x1000 0054)) = 0x0;" is meant to clear a memory location that is needed by the USB ROM code, you only need to do this when calling the USB_ISP code from your user program.
And yes, unit32_t is a type - it should be u[COLOR=Red]int[/COLOR]32_t.

Rob

[lpcware]

Content originally posted in LPCWare by BPC on Tue Nov 29 10:25:15 MST 2011
I have the LPC1343 configured as a VCOM with PIO0_1 pulled high and it's working great.  Now I want to be able to update my firmware (through software) without using the programmer.  Since I have PIO0_1 pulled high, does that inhibit me from entering ISP mode?

I am using the autoisp example and everything appears to be working up until the point where the device should show up as a mass storage device.  I have verified that the WDT is working and the device is resetting (10 seconds on, 45 seconds off, etc...), but  "LPC134x USB VCom Port" is always present in device manager, where I was expecting it be change to a MSD.

I saw the bootloader note *((unit32_t *)(0x1000 0054)) = 0x0; (typo?), but I get a compiler complaint using that syntax.  Any advice?

Thanks.

[lpcware]

Content originally posted in LPCWare by BPC on Thu Nov 17 13:56:28 MST 2011
Nevermind...please ignore the previous post.

[lpcware]

Content originally posted in LPCWare by BPC on Wed Nov 16 10:42:22 MST 2011
Rob,

Thanks for your reply.  I was able to get your code working with my modified cdc (VCOM) example.  Basically, I am constantly sending 16 ADC channel readings at a rate of about 10Hz to my CPU as my main loop.

Now that I added and modified your I2C code, I can't seem to get a handle on the interrupt for the I2C.  I would like to send 1 page (16 bytes) of my EEPROM data at a rate of about 1Hz to my CPU, but the way the interrupt is working, it is sending at about 100Hz.

I can probably figure this one out myself, but figured it would be worth a post.

Thanks,

Brian

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Nov 15 12:46:10 MST 2011
Brian,

---

Quote: BPC

I've worked with I2C on a few different MCUs, but not with the 1343.  I think I'll give it a shot today.

As always, any pointers in getting started are much appreciated.

---

It is an old thread but in this thread there is a zip file with 'my' original I2C driver that I still use. The thread contains a lot of interesting discussions about the I2C driver and how it should work according to some forum members.
'My' driver is not ny own piece of work but just a debugged and enhanced version of the original NXP code.

Rob

[lpcware]

Content originally posted in LPCWare by BPC on Tue Nov 15 09:49:27 MST 2011
Rob,

Thanks for the reply.  In regards to eliminating sprintf, I was able to implement Zero's method below, and have opened up about 10kB of code.

I actually have a small I2C EEPROM on my board and I'm somewhat torn between storing my calibration data in the EEPROM or trying to store it in flash.

I've worked with I2C on a few different MCUs, but not with the 1343.  I think I'll give it a shot today.

As always, any pointers in getting started are much appreciated.

Thanks,

Brian

---

Quote: Zero
Don't know what you are trying to do, but a simple approach to convert simple floats with a few decimals is to use itoa :eek:

#1 Cast float to int, itoa to string

#2 Add '.' to string

#3 Subtract casted int from float to get mantissa

#4 Multiply mantissa with 1000 to get 3 decimals

#5 Add itoa of mantissa to string

#6 Close string with '\0'

Sample 234.678 = "234" + '.' + "678" + '\0'

---

[lpcware]

Content originally posted in LPCWare by Rob65 on Tue Nov 15 00:08:33 MST 2011

---

Quote: Zero
I don't like storing data in MCU flash since EEPROM (smaller, SOT23-5) / FRAM (faster, SO8) / RTC (NV-RAM) is able to store my data :rolleyes:

---

But that means adding extra components so this votes yeah for storing data in Flash :eek:
One very good reason for not storing data in flash is that you will loose this data when reprogramming your flash with a new software version. Meaning that you have to recalibrate - something you don't want in a running product.

I calibrate my hardware before final assembly. Calibration is done using a separate test program that also tests the other hardware interfaces on the board.
This may sound like something only being used in a real production line but I even use this for my (sometimes just one off) prototypes: After my hardware is done (sometimes a real PCB, sometimes a perfboard with my module on top) I start writing a basic program that verifies all (hardware) connections; are all my keys connected to the correct I/O lines, do LEDs/motors/relays etc. act as expected, are the A/D and D/A interfaces getting the correct data, etc.
Very useful - it saved me quite some time looking for bugs in my code where the problem was in the hardware :D

---

Quote: BPC
I can't seem to figure out how to convert a float to a string properly  (without using sprintf) ...

---

Why not (try to) use fixed point. I.e. instead of using a float with the value 234.678 use an integer with the value 234678. This does limit you in the kind of calculations you can do but in the end it saves a lot of memory and processing time.
The trick is to start thinking fixed point bottom up. If this is an A/D value you want to convert with a 3.222 mV step (3.3 / 1024) and you want the value in mV, the floating point way would be to multiply by 3.222. Instead multiply by 3222 [uV] (integer) which will give you the value in uV and then divide by 1000. Always (really always) check for overflow on your 32 bits integer; in this case intermediate results will never be larger than 3,300,000

---

Quote:
... and without rounding off my numbers

---

We are always rounding off numbers ...
Floating point numbers have only 6-9 significant decimals. The problem is that you never know when rounding will take place.
In this case (A/D conversion) I specify my calibration value in uV and do all calculations in uV - there is no way for me to reach a higher accuracy with the calibration equipment I have.

Rob

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Nov 14 16:21:59 MST 2011
Don't know what you are trying to do, but a simple approach to convert simple floats with a few decimals is to use itoa :eek:

#1 Cast float to int, itoa to string

#2 Add '.' to string

#3 Subtract casted int from float to get mantissa

#4 Multiply mantissa with 1000 to get 3 decimals

#5 Add itoa of mantissa to string

#6 Close string with '\0'

Sample 234.678 = "234" + '.' + "678" + '\0'

[lpcware]

Content originally posted in LPCWare by BPC on Mon Nov 14 15:23:34 MST 2011
I can't seem to figure out how to convert a float to a string properly (without using sprintf) and without rounding off my numbers :(.

I have a numbers coming in such as 148.2 or 1.354 and I need to send the entire number over the serial buffer (including decimal places).  I was using sprintf without any trouble...except for code size.

Any help is appreciated.