Using STLINK or TI ICDI to debug/program LPC1700 MCU

[lpcware]

Content originally posted in LPCWare by izico on Fri Sep 13 17:53:04 MST 2013
Hi, I dislike the proprietary tools from Code Red, but I love the price of NXP LPC very much, I don't understand why NXP buy this company and game over their old strategy to support simultaneously the 3 main stream development tools - Keil/IAR/GCC, which is my preferred solution because it gives us more choices, and we can figure out to use other free tools with the examples of these 3 very different main stream development tools.

Preferably I love to use a free and open source tool to develop, I used gcc/openocd/eclipse successfully for both STM32 and TI Stellaris in the past.

ST has the ST-LINK JTAG/SWD probe on their cheap demo board, and TI has the ICDI on their cheap demo board, and I used these on board JTAG/SWD probe to debug/program my own custom board.

But I've not been successful to use ST-LINK with my LPC1769 LPCXpresso board yet.

In order to find the problem/solution, I tried using Keil ARM-MDK, I've succeeded to debug the LPC1769 with the STLINK by now, but unable to program the flash yet, I feel it may not be able to do it after my further study and trial.

Anybody have ever succeeded to debug/program the LPC17xx with either ST-LINK or TI ICDI using any development tools? If so I guess I can find a way to make the openocd to work too.

Don't suggest other working JTAG debuggers, I know this but I don't want to buy more debuggers; and don't suggest using the crt_emu_lpc11_13_nxp command line tool of Code Red too, I know how to communicate with this gdbserver too; I want a totally different and preferably open source free tool.

I'm open to buy another working JTAG/SWD debugger on some other cheap development boards, such as the damned LPC-LINK on the LPCXpresso board (NXP is just mad to use a LPC3154 to debug a LPC1114, but good news is that I have a LPC3154 demo board too if I need to use this high end chip in some products).

I don't think any expensive standalone debugger deserve their high price, these on board debugger on these very cheap development boards is fantastic to beat them in both price and usage.

[lpcware]

Content originally posted in LPCWare by fjrg76 on Thu Apr 16 21:50:58 MST 2015
Hi, Is there any entry blog where you explain what you did so you were able to use the st-link probe?

I love NXP tools, but would be nice to detach the projects from any particular vendor (one may try the newest g++ features, say C++ 14 =) )

LPC1769 is quite expensive, so to reach a $10 per board is not profitable.

[lpcware]

Content originally posted in LPCWare by mburton on Fri Sep 27 23:40:29 MST 2013
Hi Izico,

It sounds like what you want is an LPC version of the STM32 F3 discovery board which contains an M4 processor and some interesting peripherals (and pretty LEDs), access to all MCU pins, and an on-board stlink-v2 (which also has the SWD pins broken out so you can use it to program other MCUs) and only costs around 10 pounds - outstanding.

Cheers,

Mark

[lpcware]

Content originally posted in LPCWare by izico on Fri Sep 27 17:38:33 MST 2013
And another business idea pop up after my study of LPC, I'm sure many other developers need it just as I need it currently, but I'm not sure if it's profitable.

We don't know which exact LPC fits our need before hand most of the time, and we may need a demo board to try a lot MCU to decide on the ones to be used, and designing and prototyping new PCB is too expensive and time consuming.

But the current demo boards on market are all quite full featured with a lot useless parts that we may never need and very expensive (no one below US$10 in my search).

As a developer, I just need a demo board that can work after plugging some kind of power supply to the board, and expose all the MCU pins for easy connection outside for my test and try, I can connect the JTAG/SWD debugger and any other peripherals myself.

There's some kind of simple minimalist boards on market, but too expensive (above US$10).

I've an idea to design a demo board which can be used for as many kind of LPC as possible, and I'll just leave the solder point for the MCU on the PCB, the developer can buy their preferred MCU and solder it on board themselves (of course I can do this for them too with the money compensation), this way the board will be very cheap.

I have studied extensively the user manuals and datasheets of all LPC series from NXP websites, I've planned to do 2 boards initially for seemingly the most used and chased LPC on market:
1. a LQFP48/64 double sided board to be usable for any LPC11xx and LPC13xx MCU
2. a LQFP80/100 4 layers board to be useable for LPC175x/6x MCU

And I've estimated that if I price both at about US$1.5, I can still profit, and this looks to be a unbeatable price in comparison with any other demo boards on market.

I'm not sure if this is a profitable business to earn some extra money, I plan to do this in my free time in next month.

[lpcware]

Content originally posted in LPCWare by izico on Fri Sep 27 17:17:16 MST 2013
Hi, Mark,

I've made it work too after some study and google, and below is perhaps the shortest working script, It's for the LPC1769 only, I guess it'll be adaptable to other LPC1700 series MCU, I've used it to debug and flash, both works well.


izico@kubuntu:~/tmp$ cat openocd.cfg
set _CHIPNAME lpc1769

source [find interface/stlink-v1.cfg]
transport select hla_swd

hla newtap $_CHIPNAME cpu -expected-id 0x2ba01477

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME stm32_stlink -chain-position $_TARGETNAME

$_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000

set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 4000 calc_checksum

$_TARGETNAME configure -event reset-init {
    # remap flash to 0x0
    mww 0x400FC040 0x01
}

izico

[rayaan]

Hi Izico,

I just wanted to ask if you would be so kind as to share how you set up you openocd and config file, I would like to use a st link v2 to flash lpc1764 chip on a custom board, I also have access to a olimex tms320-xds100 jtag. any help will be highly appreciated.

Regards

Rayaan

[lpcware]

Content originally posted in LPCWare by mburton on Fri Sep 27 02:04:03 MST 2013
Hello again,

I have found that if you change the reset-init code to what's below, then you don't need to erase all the flash before programming. The difference is that I have added a line to switch the CPU clock back to the input clock and not the PLL output. I think the problem is that due to lack of srst, the chip isn't getting completely reset and so having run the program once, the clocks are far too high and so the flash programming timing is wrong. You have probably guessed by now that I am a complete newbie when it comes to openocd configuration.

Cheers,

Mark

-----------

$_TARGETNAME configure -event reset-init {
# Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
# "User Flash Mode" where interrupt vectors are _not_ remapped,
# and reside in flash instead).
#
# See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit description
# Bit Symbol Value Description Reset
# value
# 0 MAP Memory map control. 0
# 0 Boot mode. A portion of the Boot ROM is mapped to address 0.
# 1 User mode. The on-chip Flash memory is mapped to address 0.
# 31:1 - Reserved. The value read from a reserved bit is not defined. NA
#
# http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user

mww 0x400FC040 0x01

mww 0x400FC104 0x00000001; # Setup Clock Divider
#  mww 0x400FC10C 0x00000000; # Select Clock Source for PLL0 & sysclk
#  mww 0x400FC1C8 0x00000000; # Clock Output Configuration
}

[lpcware]

Content originally posted in LPCWare by mburton on Thu Sep 26 16:08:04 MST 2013

I forgot to include the top-level config file, I shall paste it below.

One thing I have just noticed is if I try to program the flash without explicitly erasing it first (using mb_flash_hex below) then I get a whole bunch of bytes not comparing right. But if I erase the flash first, everything is OK (apart from the checksum bytes, of course). This didn't happen before when I was using another JTAG adapter (jtagkey or olimex). Using the stlink adapter is over twice as quick at flashing as those jtag adapters so perhaps the problem is speed related. Erasing first and then flashing seems reliable.

Cheers,

Mark

############################

source lpc1788-stlink.cfg

adapter_khz 1000

#reset_config srst_only
reset_config trst_and_srst

proc mb_flash {IMGFILE} {
   flash write_image erase $IMGFILE
   catch { verify_image $IMGFILE }
   reset run
#   shutdown
}

proc mb_flash_bin {IMGFILE OFFSET} {
   flash write_image erase $IMGFILE $OFFSET bin
   catch { verify_image $IMGFILE $OFFSET }
   reset run
#   shutdown
}

proc mb_flash_hex {IMGFILE} {
   flash write_image erase $IMGFILE 0 ihex
   catch { verify_image $IMGFILE 0 }
   reset run
#   shutdown
}

proc eraser {} {
# Verbose procedure confirmed erase routine
   flash erase_sector 0 0 last
   flash erase_check 0
   soft_reset_halt
   shutdown
}


#debug_level 3

init
reset init
arm semihosting enable

############################

[lpcware]

Content originally posted in LPCWare by mburton on Thu Sep 26 15:27:50 MST 2013
Hi izico,

I have been trying to use the stlink v2 dongle (nice and cheap!) with an lpc1788 board and have just managed to get it working (a quick test shows that I can flash and use gdb to step but I haven't had time to give it a real good checkout).

Anyway, have a look at the attached openocd config files. Please let me know if you find any mistakes!

BTW - I am using the current master branch from the openocd git repo.

Cheers,

Mark