Hi all,
I am working on Xcore 200 platform (XU232 processor) on a custom bootloader.
Due to some early hardware design, I have two ports on different tiles (on tile 0 and tile 2) and I need to access them during the bootloader step. However, the init() function of the bootloader (where I want to do my port access) seems to be only on tile 0.
Can I do some multi-tile port access in bootloader code ?
The compiler raise error when I use some "par" statement with "on tile" options :
[quote]loader.xc:50:6: error: can only specify 'on' in function `main'
on tile[0]:
^~~~~~~
loader.xc:88:6: error: can only specify 'on' in function `main'
on tile[2]:
^~~~~~~[/quote]
Thank you,
Marc
Bootloader multi-tile ports access
-
MarcAntigny
- Active Member
- Posts: 61
- Joined: Tue Feb 13, 2018 2:50 pm
-
MarcAntigny
- Active Member
- Posts: 61
- Joined: Tue Feb 13, 2018 2:50 pm
Hi mon,
I think I was not clear on what I wrote. The bootloader is the part of code (usually named "loader.xc" in XMOS documents) called at start-up of the XMOS processor. See chapter 4 in https://www.xmos.com/developer/download ... 78A%29.pdf
I know how to add parallel threads in a "traditional" firmware but for the bootloader piece of code, it doesn't seem to work and I could not access all the tiles (only tile 0). So my question was : is it possible to do such access in bootloader piece of code (like in normal firmware) or is there some specific limitations ?
Thank you,
Marc
I think I was not clear on what I wrote. The bootloader is the part of code (usually named "loader.xc" in XMOS documents) called at start-up of the XMOS processor. See chapter 4 in https://www.xmos.com/developer/download ... 78A%29.pdf
I know how to add parallel threads in a "traditional" firmware but for the bootloader piece of code, it doesn't seem to work and I could not access all the tiles (only tile 0). So my question was : is it possible to do such access in bootloader piece of code (like in normal firmware) or is there some specific limitations ?
Thank you,
Marc
If you refer to AN00238 in the examples, it appears you can build a bootloader that has functions will be called from both tiles... note this is for SPI slave bootloader but it may work for flash bootloader (maybe it won't, I don't know).
So you could check which tile your functions are running on and then do different stuff accordingly, e.g. by executing primitives to read the state of the hardware ports you want on each tile. If you need to communicate between the two tiles you could setup the switch network and call the primitives like XMOS does in the example. I don't know if you'll be able to do this with the existing loader.xc interface or if you'll need to build your own libloader.a like they do in the example. Perhaps start by seeing if you can determine if the init() function is called from both tiles or just tile 0 (e.g. by reading the tile id and then performing some different action depending on what tile you're running on). It's probably just tile 0 but if it already runs on both tiles you probably won't have to build a libloader.a and just call the primitives to read the hardware ports.
If you need to write your own libloader.a then it would probably be easier to change the hardware so you only have to access tile 0... but it looks like it should be possible to run bootloader code on both tiles and communicate between those tiles if absolutely necessary.
So you could check which tile your functions are running on and then do different stuff accordingly, e.g. by executing primitives to read the state of the hardware ports you want on each tile. If you need to communicate between the two tiles you could setup the switch network and call the primitives like XMOS does in the example. I don't know if you'll be able to do this with the existing loader.xc interface or if you'll need to build your own libloader.a like they do in the example. Perhaps start by seeing if you can determine if the init() function is called from both tiles or just tile 0 (e.g. by reading the tile id and then performing some different action depending on what tile you're running on). It's probably just tile 0 but if it already runs on both tiles you probably won't have to build a libloader.a and just call the primitives to read the hardware ports.
If you need to write your own libloader.a then it would probably be easier to change the hardware so you only have to access tile 0... but it looks like it should be possible to run bootloader code on both tiles and communicate between those tiles if absolutely necessary.