Wolf JTAG programming vectors

[mguermandi]

Hello, I'm building an application for PULP JTAG programming from MCUs. For that, I need the stimuli vectors (i.e. sequence of 32-bit L2 mem address - 64 bit L2 mem data) to send to Mr.Wolf on the JTAG. When I compile a PULP application on my SDK (release 2018.07.03), I can't see any file containing them, both compiling for platform board and platform rtl. For now, Davide provided me with a workaround (and it works fine) but it would be nice to have a build option which would either generate a txt file with the stimuli vector or, even better, a header file with a uint32 array for the addresses, and a uint64 array for the data. Thanks!

[politicante]

The 64bit was used in the old PULP chips up to GAP8. From mr.Wolf we are using a 32bit soc interconnect and 64bit writes are no more possible so I suggest that both array should be 32bit

[mguermandi]

I see what you mean now. Agreed 32-bit is better. It would probably be nice to store the address array in a compact way, i.e. storing only the jumps which are larger than 4 bytes.

[haugoug]

The SDK is producing an ELF binary when you compile the test. All the information you need are inside the ELF binary and you should do the loading with this ELF file, not with a stimuli file, even if you do it from an MCU.

[daviderossi1982]

Let me reformulate the question. Marco is realizing a very small application board (40x20mm) hosting Wolf + one nrf52832 MCU (featuring a cortex M4 CPU + FLASH memory + BLE) + one ADC. We cannot afford any other components on this board, i.e. we don't have any SPI flash or hyperflash on board. Since it's an application board we want to have the program for wolf stored in a non-volatile support, and the only non-volatile support is the flash inside the MCU. Then, for the boot of Wolf we have the GPIOs of the MCU connected to the JTAG of Wolf, basically the MCU it is emulating what happens on the tester using its GPIOs. At the moment we are taking the elf file, transforming it into .s19 with objcopy, then using parse_s19.pl and finally creating an header file for the MCU application. On the board the MCU loads the program into the L2 of Wolf through the JTAG.

The questions are:

1) Would it be possible to create another target in the makefile to create directly this header file when we compile an application for wolf, and integrate in into the SDK?

2) Do you have any other suggestions (given the hardware setup I have described?)

[haugoug]

This looks like a very specific solution, so I would prefer to keep it out of the sdk where I try to keep generic solutions, which is why I always use ELF files unless it is impossible (like with system verilog testbench). You could embed the ELF binary within your MCU binary and also an ELF loader so that you go through the ELF header and generate the JTAG accesses according to that. If you really don't want to go for an ELF solution, we can modify the runner to call a script that will do the work. Then it depends if you want a full support of this board by the SDK ?

[politicante]

Hi Germain,I think this solution is not so specific. It will be useful in any system where PULP is loaded by another uC.I think having the sdk generate directly the .h file with the binary is not a bad idea.

Ciao Antonio

[haugoug]

Ok let's say it is specific to MCU then although I would personally do it with ELF loading. Marco, you don't need any option for that, the generation of stimuli is done by the runner, you can find it there: git@github.com:pulp-platform/runner.git and is under tools/runner when you build the sdk from sources. The fonction "prepare" is called when you do "make all" and can then be used to produce specific files for the target after the binary is produced. You can contribute your modifications to a branch and I'll put an option so that you can activate it for your board. You have to add it in the file plp_board_runner.py. You can have a look at plp_rtl_runner.py also to see how it is done on the rtl platform. Let me know if you need more information.

[daviderossi1982]

Hello Germain,

I create a new branch in git@github.com:pulp-platform/runner.git --> header_integration. I have added the file bin/s19toheader.py into this branch and modified python/plp_board_runner.py to call the script as you suggested. Marco has also created a c file for the MCU which loads the header generated to Wolf. I think it would be good to have it somewhere inside the SDK to be used as reference. Where do you think we can put it?

[haugoug]

You can also put it in the runner under a new sub-directory, I usually put all tools for running on the target under this module

[daviderossi1982]

hello Germain,

I have added the files in the tools directory in the runner, branch header_integration.

Davide

[haugoug]

Ok great, I would prefer to generate the header only when needed, is it fine if I add a board option so that this triggers the generation ? In this case which name would you like ?

[daviderossi1982]

yes it is fine, for what concerns the name you can choose one depending on your naming conventions, one possible option could be "header", or something similar...

[haugoug]

I can put an option if you prefer that you'll have to active like this: make run PLT_OPT="--header" I was more thinking to automatically activate it depending on the board, so I would need a name for your board liek "mcu" or "stm32"

[haugoug]

I've integrated your modifications, this will be in the next tag, probably today. You can now trigger the header generation with this command: make runner RUNNER_CMD=header You can also combine it with other targets: make clean all runner RUNNER_CMD=header I've removed the tools directory, it is too big for this runner repository which is used by all platforms and should be kept small. You should move all these files to a repository specific to your platform, a kind of BSP. Let me know if you need any help for that.