This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

custom serial wire debug

Hi, As question "custom serial wire debug" date Jan 14 '14, I'm also interested in programming the chip from an other embedded chip (would fit our production process verry well).

Do you have information about how to do this?

After looking at data sent on DW when using the dev-board "nRF51 DK" i notice that different code seems to be written to ram @ 0x20000000..0x200004BF.

Is this code avaliable?

May I use it myself in an own construction targeting your chip (or do you consider the code your property and I may not use it)?

(Or even simpler, can I program through AHB-AP directly without using a ram algorithm.)

Parents
  • It's not Nordic's code doing the programming from the nRF51 DK, it's the on-board Segger chip which is programmed with Segger's JLink software, that's what's talking SWD to the nrf51 and is connected out of the board via USB. In all likelihood Nordic just uses JLinkDLL, which is Segger's wrapper library for the whole thing, which provides you simple high-level functions to write to registers, read and write files etc. I didn't know JLinkDLL wrote to RAM, but I guess it might, I'll have to look one day. Possible that Nordic's nrfstudio uploads a bootloader to RAM and then runs it, Crossworks does that (or did before Segger provided a generic flash loader), but I didn't think so, you don't really have to, JLinkDLL provides all this in 2 dozen c functions.

    If you have an SWD emulator library for the big ARM CPU you may be able to make use of that, but you'll have to do the pretty low-level work yourself. Again depends a bit what libraries exist already for the CPU you're using.

    Nordic has a bootloader/DFU module. You have to get it on the chip in the first place but you can then talk to that over UART if you like, with a very simple protocol. That doesn't help you get the initial image on however.

  • Well the bits I know are correct are

    1. On the nrf51 DK the SWD pins are connected to the on-board Atmel chip (ATSAM3U2CA) which drives them and emulates the SWD protocol
    2. That Atmel chip runs JLink-OB from Segger (or it can run an mbed stack instead but by default it's segger) all controlled by USB, also implemented on that chip.
    3. That's all driven by a higher-level library from the host. As the Segger protocol is only very sparsely documented and they provide a cross platform JLinkDLL library which implements it (for a fee) I know of nobody commercially using Segger who doesn't use the library and I would be 99.9% sure Nordic does too. It's a no-brainer if you are a Segger shop, JLinkDLL is really easy to use, especially for the minimal stuff nrfstudio needs to do.
Reply
  • Well the bits I know are correct are

    1. On the nrf51 DK the SWD pins are connected to the on-board Atmel chip (ATSAM3U2CA) which drives them and emulates the SWD protocol
    2. That Atmel chip runs JLink-OB from Segger (or it can run an mbed stack instead but by default it's segger) all controlled by USB, also implemented on that chip.
    3. That's all driven by a higher-level library from the host. As the Segger protocol is only very sparsely documented and they provide a cross platform JLinkDLL library which implements it (for a fee) I know of nobody commercially using Segger who doesn't use the library and I would be 99.9% sure Nordic does too. It's a no-brainer if you are a Segger shop, JLinkDLL is really easy to use, especially for the minimal stuff nrfstudio needs to do.
Children
No Data
Related