Hello ,
I tried compiling the USB bootloader code here :
http://www.sparkfun.com/commerce/tutori … =94&page=3
with WinARM,but in the first try it threw up :
SYSTEM/rootdir.h:1:20: error: stdint.h: No such file or directory
Does anyone know where I could find the files ?
Okay I got the WinARM issue resolved,by changing the makefile. I was able to compile and load the hex file using the Philips ISP utility.
After loading I get the messages on the UART etc indicating the LPC is working.
The first time I plugged in the board XP displayed as “LPCUSB memory” or something like that.
But now I get a message from windows :
USB device not recognized.
I have my own LPC2148 board,based on the Olimex board.
An IAR hex file for HID,which I loaded and tried also works fine,I am able to scroll the mouse with a potentiometer.
Is there anything I could try out to solve the problem ?
I am trying the example without an SD card attached , just for trying the USB functionality.
As the LPCUSB is viewed as mass storage device, the SD card should be inserted to be correctly read by windows :roll:
Angelo
Well , not quite.
If you see the code, before the SD card is checked for , the code checks if USB is plugged in :
if(IOPIN0 & (1<<23))
and it calls the initilializing function which infintely loops up at
while (IOPIN0 & (1<<23))
{
USBHwISR();
}
Nothing to do with the SD card thus far.
Also the problem is erratically I get WinXP recognizing the board and showing up the board as a drive.
But even then it loops at that place.
Hi Thomas.
“TF” == thomas fernando <thos_fernando@yahoo.co.in> writes:
TF> Ok I have designed my LPC2148 board which is the same as the
TF> one you posted here:
TF> except that R17 is 2k on my board.
That schematic is actually just the Olimex LPC2148 header board. But
the circuitry is the same on their development board too, and both
work OK for me.
R17 is the resistor USB uses to detect the speed of a device that’s
connected. Per the USB-2.0 spec:
7.1.5.1 Low-/Full-speed Device Speed Identification
The USB is terminated at the hub and function ends as shown in
Figure 7-20 and Figure 7-21. Full-speed and low-speed devices are
differentiated by the position of the pull-up resistor on the
downstream end of the cable:
the pull-up resistor on the D+ line.
the pull-up resistor on the D- line.
resistors of 15 kΩ ±5% connected to ground.
The design of the pull-up resistor must ensure that the signal
levels satisfy the requirements specified in Table 7-2. In order
to facilitate bus state evaluation that may be performed at the
end of a reset, the design must be able to pull-up D+ or D- from 0
V to VIH (min) within the minimum reset relaxation time of 2.5
μs. A device that has a detachable cable must use a 1.5 kΩ ±5%
resistor tied to a voltage source between 3.0 V and 3.6 V …
There are some sample schematics there too. 2K is out of spec, but I
think it’s probably close enough, since you’re having success with the
HID example.
TF> I use WinARM.
I only use GCC on Linux; I probably tried a Windows development
package years ago, but I’m only really familiar with GCC.
TF> To have a preliminary test : I have loaded the IAR , HID
TF> example , which works perfectly 100/100.I am able to scroll
TF> the mouse etc.
Sounds like your hardware is fine. One thing I do when I’m having
trouble with a uC design is flash and run the simplest “Blink” code
after 5-6 failures with new code. That sort of resets the clock, so I
don’t waste time trying to debug a program, when the problem really is
that I haven’t been downloading successfully.
TF> I do not have the IAR compiler,so I just tried with the hex
TF> file. I then tried the JC Wren code , for CDC , serial port ,
TF> which worked a couple of times and does not do so now.This
TF> code had too many features , so I parked it.
JCWren’s code is very useful for reference, but I think the USB
section is based on a slightly old version of Bertrik’s code. And
Bertrik’s code is also a little hard to follow, although I use the
serial/CDC version successfully in one of my projects.
TF> I am now using the Sparkfun USB boot loader example ,which I
TF> am able to compile and try out on my board. The entire
TF> episode is on :
I tried the Sparkfun USB boot loader, but I never got it to work, and
it didn’t do what I wanted anyway. I wrote a different boot loader,
based on Bertrik’s code, that works like this:
connected:
% Identify as serial port
% Read simple commands from host over serial port
% If the host sends an Intel HEX file, program it into Flash
% If the host sends a “reset” command, start executing as below
% Look in a special location (I don’t remember exactly where, maybe
@0x2000?) for a valid vector table
% If vector table is present, copy it to RAM and remap the vector
table pointer
% Transfer control to that reset vector.
So, you can plug in the board and (quickly) do "copy Program.hex
/dev/ttyUSB" and it’ll program the Flash. Reset the board and wait a
few seconds, and the bootloader will start the new code.
It’s handy for me because the LPC2148 header board doesn’t have an
RS232 port, so I can’t use the Philips ISP.
This code is all available on the Yahoo LPC2000 group site at:
http://tech.groups.yahoo.com/group/lpc2 … es/USBoot/
There’s also a HEX image that you could install if you can’t compile
the source.
One thing I thought of while looking at your SparkFun post: the
infinite loop
while (IOPIN0 & (1<<23))
{
USBHwISR();
}
is running the USB code in polled mode, instead of real interrupt
mode. If you’re not polling fast enough, it won’t work reliably.
Make sure you set the PLL on the chip as fast as it’ll go (60MHz). I
think you can probably use USB with the main oscillator going as slow
as 24MHz or maybe 48MHz, but only if you use good interrupt code.
Anyway, if the HID example works reliably, your hardware is probably
OK. If you’re having enumeration problems (the host doesn’t detect
the device type properly) then it’s likely logic or timing issues with
the code running the 2148 USB peripheral. Also, since it sounds like
you’re using various different people’s USB code, I think you’re going
to have a tough time debugging. USB is so complicated, that if you
don’t understand everything that’s supposed to happen, you won’t be
able to find the spot in the code that needs fixing.
I was pretty lucky that Bertrik’s code worked the way I wanted for my
boot loader. I haven’t been able to get it to do what I want for my
next project, so I’m trying to write my own stack so I understand it
well enough to make big changes.
Good luck.
d.
Hi Dave,
Obliged for that exhaustive post from you.
This discussion is also cross posted here :
http://tech.groups.yahoo.com/group/lpc2 … sage/37839
I just loaded your hex file.The behaviour was the same as when I load all the code for the first time.Windows pops up a message asking for drivers.
With JC Wren’s code there was a folder,where he had placed the windows drivers. I had used those. Should I use the same with your hex ? I did not proceed with this.
Could you give me a hex file which write out a message on the USB ( COMPort ) so that I could run it a couple of times ? My board uses a 12MHz crystal.
The idea behind using varied code is just to see if I can rule out hardware being a problem.Once I am satisfied with that ,I could work on the USB firmware part.
I have since changed the resistor to 1.5k , but does not seem to make any difference.
I doubt that its a software loading issue , because I periodically change the messages popped out on the UART , and each time I get those with absolutely no problem.
Thanks again for your post.
emb_sys_dev:
I just loaded your hex file.The behaviour was the same as when I load all the code for the first time.Windows pops up a message asking for drivers.With JC Wren’s code there was a folder,where he had placed the windows drivers. I had used those. Should I use the same with your hex ? I did not proceed with this.
It’s probably the same driver. I’ve never had to fiddle with it, since apparently the driver is built in or automatically findable by Ubuntu.
emb_sys_dev:
Could you give me a hex file which write out a message on the USB ( COMPort ) so that I could run it a couple of times ? My board uses a 12MHz crystal.
I modified my USBoot code slightly to simply interact with the user over the CDC com port. It’s up on the Yahoo files site:
It’s linked to be written into Flash at address 0x00000000, and I think it runs the PLL at 60MHz (given a 12MHz crystal).](http://f1.grp.yahoofs.com/v1/EJQwSSXhlrTKZDktrzmbktfoD-o5nkVrBQt1v3xn6em8uj7dePUhN0oa2seXn4kMlemkCiP2vVNC9nxHsY2mkYACZfYLk-fXz-fxy40/TFTest.hex)
Dave ,
Your software works perfectly. It emulates as COM6 on windows , I guess the weird COM number is an XP sin.I could probably fiddle with the registry and modify it,when required.
Your software does this :
software by dave
argv[0] = “software”
argv[1] = “by”
argv[2] = “dave”
LPC2148 ARM USB board
argv[0] = “LPC2148”
argv[1] = “ARM”
argv[2] = “USB”
argv[3] = “board”
I have done as much “testing” as possible , and it looks good. So I think the hardware could be said to be OK.
Would you be in a position to put up the source for this ,so that I can use it as a reference ?
Cheers and thanks again.
emb_sys_dev:
Would you be in a position to put up the source for this ,so that I can use it as a reference ?
I accidentally picked an old test program to make that out of, so it had a lot of weird dependencies and cruft (it would be hard to find and upload everything needed to build it, and hard to build unless you had my whole exact setup).
Instead, I added a new example program to my lightly-modified LPCUSB package, which does more-or-less the same thing (it’s a read/print loop that talks to the user over a CDC-USB connection).
The tarball, including compiled hex files, is [here.](http://f1.grp.yahoofs.com/v1/AGcxSVOz57SOf0Yhy6QBho393YQcXU0CaAaKOrDE-aQQoxrFsywT2__jWfKjScF5CMgLwqUwZaQIA0zyDNkpLpiy51-A5lEzkCMUKQ0/LPCUSB.tar.gz)
Should do the job , well enough I guess. Anyway the main aim has been served,so I can work on it at leisure.
Would keep you posted.
Thanks a lot !!!
emb_sys_dev:
Well , not quite.If you see the code, before the SD card is checked for , the code checks if USB is plugged in :
if(IOPIN0 & (1<<23))and it calls the initilializing function which infintely loops up at
while (IOPIN0 & (1<<23))
{
USBHwISR();
}
Nothing to do with the SD card thus far. Also the problem is erratically I get WinXP recognizing the board and showing up the board as a drive. But even then it loops at that place.
Well, actually USBHwISR() will access the SD card. The part you are confused with, is that the SD card access that occurs later in the code is to read a firmware update file from the SD card. The USB MSC is used to put a file onto the SD card.
Mike
Hi Dave,
I just put some files here :
http://tech.groups.yahoo.com/group/lpc2 … s/LPC2148/
which were compiled with WinARM.
The hex file from this does not work,while yours works 100/100.
Could you glance at it , your time permitting ?
The hex file works now,when compiled with WinARM.
I had to compile with optimization=0,previously it was optimization=s.
This is a temporary workaround.
Cool. Sorry I haven't had a chance to try your code yet -- I've been neck-deep in a USB problem on another ARM chip (LM3S5732) that turned out to be sort-of timing related. My code would run with debugging messages turned on, but not with them turned off. I was not waiting for the appropriate trigger before setting the device address after a SET_ADDRESS command, but with the messages printing out, the trigger would already have happened by the time I set the address.emb_sys_dev:
The hex file works now,when compiled with WinARM.I had to compile with optimization=0,previously it was optimization=s.
I don’t know anything about WinARM…does “s” optimization cause Thumb mode or something? Your ISR MUST start in ARM mode, although it can switch to Thumb immediately if you want. (Sorry if this is insultingly basic.)
(Edited:)
You know, now that I think about it, maybe you are having ARM/Thumb problems. One of the files in that program, armVIC.c, must be compiled in ARM mode. I think crt.s uses ARM instructions, too.
You’d expect the compiler / assembler to give errors if you try to use ARM instructions in Thumb mode, but maybe it tries to “do the right thing,” and it’s not succeeding.
Anyway, that’s what I’d look into.
OK, I downloaded your RAR file, fiddled with the Makefile and some #include statements, and compiled the code. It works on my Olimex board, so I think you’ve got toolchain issues. (I’m using self-built GCC-4.3.2 and binutils-2.18.)
Time to dig into the docs for WinARM, I guess.
You know, now that I think about it, maybe you are having ARM/Thumb problems. One of the files in that program, armVIC.c, must be compiled in ARM mode. I think crt.s uses ARM instructions, too.
Actually the makefile already has instructions :
SRCARM += armVic.c
ASRCARM = crt.S
which compile in ARM mode,but let me check further.
Not linked to your problem of course, In this code, its the opposite , with the DBG messages on , the USB shows up as a COM port, but hangs when messages are passed from the PC on the COM port.My code would run with debugging messages turned on, but not with them turned off.
BTW the DBG idea is a cute one for turning on and off the debug messages with a single #define !!!
Thanks .....OK, I downloaded your RAR file, fiddled with the Makefile and some #include statements, and compiled the code. It works on my Olimex board, so I think you’ve got toolchain issues. (I’m using self-built GCC-4.3.2 and binutils-2.18.)