Okay, using the bootloaders for these LPC1xxx devices is just not going to work for me. Unfortunately my FTDI based Olimex programmer doesn’t have what it takes for SWD.
I’m currently using Crossworks, and I’ve done a bit of investigation. It looks like my only option at the moment is the J-Link debugger which is $$$ for me. Googling around, it looks like Paul is planning on adding SWD support for the Luminary Micro devel kit programmer. Also, he’s planning on selling an SWD adapter for FTDI based programmers. I have no idea when these will actually come out.
I’m just looking for confirmation that what I said above is true and/or if there are any other low cost options. I haven’t done a lot of investigation into the tech specs, but it seems to me that SWD is easier to support hardware wise and there would be some nice low cost adapters becoming available soon with the introduction of all these CM3 and CM0 parts with SWD.
Paul mentioned in another post here that he would not be supporting the LPCXpresso hardware, which seems like a shame, since it’s so cheap and should work as a nice SWD programmer for hobbyists.
I’m not in any hurry for this, so I’ll probably be waiting for anything that shows up in the next few months that looks like it has a good performance/price.
TheDirty:
Okay, using the bootloaders for these LPC1xxx devices is just not going to work for me. Unfortunately my FTDI based Olimex programmer doesn’t have what it takes for SWD.
I’m currently using Crossworks, and I’ve done a bit of investigation. It looks like my only option at the moment is the J-Link debugger which is $$$ for me. Googling around, it looks like Paul is planning on adding SWD support for the Luminary Micro devel kit programmer. Also, he’s planning on selling an SWD adapter for FTDI based programmers. I have no idea when these will actually come out.
The first batch of devices will be delivered on 15 February.
TheDirty:
I’m just looking for confirmation that what I said above is true and/or if there are any other low cost options. I haven’t done a lot of investigation into the tech specs, but it seems to me that SWD is easier to support hardware wise and there would be some nice low cost adapters becoming available soon with the introduction of all these CM3 and CM0 parts with SWD.
Paul mentioned in another post here that he would not be supporting the LPCXpresso hardware, which seems like a shame, since it’s so cheap and should work as a nice SWD programmer for hobbyists.
There is some debate about how open or closed the LPCXpresso hardware is. I’m in direct contact with NXP about this, but whether we do anything or not is a question I cannot answer at this time. I may have a better idea after my visit to Embedded World this year.[/quote]
The first batch of adapters that convert between FTDI-based JTAG adapters and SWD-only LPC1100s are now in our office, so you can use them with CrossWorks.
My understanding is yes, they will be selling these. Version 2.0.5 has the SWD option under FT2232 properties. Unfortunately there’s not much more information than that and they haven’t put anything on the website, yet.
Hopefully I will getting one and I’ll put up a review. I’m pretty optimistic about it.
I was going to say that Paul is like Leon, everywhere on the internet I go that’s related to microcontrollers, they both have been there before and probably invented it.
I’ve also made up an LPC1114 and LPC1313 board, I just haven’t etched it yet. I’m assuming the adapter will be using the standard 10pin 0.05" header.
I checked with Paul and his adapter mates with the 10-pin Samtec header specified by ARM. There is one on the LPCXpresso board, and it can be used for debugging a different board by cutting a couple of tracks. One has to use the Code Red software, though.
I’ve been really sick for the last few days, but my SWD adapter came from Rowley so I etched a board and got it running.
Unfortunately I made a real mistake of ordering QFN chips for both the LPC1313 and LPC1114. I didn’t do my homework on the pinout. I really like QFN, but the only ground on these is the thermal pad underneath the chip, which means you can’t do them without putting a via right under the chip. On a single sided home made board, that’s pretty much a challenge.
I massacred my board trying to get the bottom ground attached. I soldered and removed the chip over a half dozen times trying different ways. I was hoping to just use a lot of solder and a small via hole and heat up a wire and push it into the bottom side of the chip, but it just would not solder in. I finally just drilled a big hole under the chip. Not big enough to remove the bottom pad all together, but easily big enough to allow me to solder to the bottom of the QFN after it was put on. It worked right away and I think I can get away with this fairly easily with the other ones I have.
Here’s pictures of the Rowley SWD adapter for FT2232 JTAG devices. I have successfully connected to the chip with it and I’m just going to start with some hello world stuff. Again, I know my poor devel board I etched is in bad shape. It took a real beating with all my experiments. I even warped it some.
I’m going to have to put Crossworks on my laptop now so I can try some programming from on the couch.
I’ve got some of the Samtec shrouded headers on order, and cables. I should have them in about a week. They aren’t stock items at Toby Electronics, they have to order tham from Samtec in the USA.
I was going to get PCBs made for the LPC1111s I’ve got, but seeing yours I might make one. They are only available in QFN at present, I didn’t realise that Farnell had the QFP LPC1114 in stock or I’d have bought those.
LPC1313 and 1114 have essentially the same pinouts so I’m using the same layout for both. I just put together the 1114 board and it was much easier to do the ground this time.
So has anybody “fixed” the LPC13XX.h and LPC11XX.H header files given in NXP’s sample code so they compile under C? For some reason they decided to use anonymous unions in their header to limit it’s usefulness. I was just going to go in and add names to all of them, hoping I didn’t break anything further on, but maybe I’m not the first person this effects.
I know Crossworks has a nice header file of its own. I hate to say it, but I really like the way the registers are grouped in structs in the NXP delivered one; similar to the AT91SAM header files from Atmel.
TheDirty:
So has anybody “fixed” the LPC13XX.h and LPC11XX.H header files given in NXP’s sample code so they compile under C? For some reason they decided to use anonymous unions in their header to limit it’s usefulness. I was just going to go in and add names to all of them, hoping I didn’t break anything further on, but maybe I’m not the first person this effects.
I know Crossworks has a nice header file of its own. I hate to say it, but I really like the way the registers are grouped in structs in the NXP delivered one; similar to the AT91SAM header files from Atmel.
We’re considering doing the same. If everybody from day one had CMSIS then it would be great. However, that isn’t the case. And the struct approach doesn’t give you the bits in each of the registers. But I like the fact that it’s not all in a flat namespace.
GPIO works fine, but I’m having a hell of a time with the UART. It’s like it’s just not interacting with the actual hardware pins. Nothing comes out and nothing goes in, though according to the debugger everything is working. Loopback mode works correctly, interrupts are being triggered. Everything is working just fine, but I’m not getting any output on the TXD and nothing on the RXD shows up. I GPIO toggled the RXD/TXD pins to make sure they are working P1.6 and P1.7 and they work fine and toggle an LED fine, so I’m kinda lost here. If I can’t find anything by tomorrow, I’ll post the hacked up stripped down code I’m trying to get to work.
TheDirty:
GPIO works fine, but I’m having a hell of a time with the UART. It’s like it’s just not interacting with the actual hardware pins. Nothing comes out and nothing goes in, though according to the debugger everything is working. Loopback mode works correctly, interrupts are being triggered. Everything is working just fine, but I’m not getting any output on the TXD and nothing on the RXD shows up. I GPIO toggled the RXD/TXD pins to make sure they are working P1.6 and P1.7 and they work fine and toggle an LED fine, so I’m kinda lost here. If I can’t find anything by tomorrow, I’ll post the hacked up stripped down code I’m trying to get to work.
Did you configure the pin’s function using the appropriate alternate function register?
Yes, I’ve change the IOCON for the pins. Sorry, that was more of a lone rant, as I can’t expect any advice without giving more information.
I’m just going to cut and paste the code that I’m working with. It’s a complete mess, because I just started grabbing code out of examples willy-nilly hoping to find out what I missed with my own code. It just send ‘b’ over and over again and toggles a status LED. I can turn on the loopback mode and the different interrupt enables. The 'tempname’s are because I haven’t really decided what to do with the nameless unions in the header file, yet.