While scanning the flash examples on github, I came across the app_factory_image_programmer. It appears to be composed of two parts, a c file (programmer.c) and an xc file (flash_connect.xc).
Programmer.c appears to run on the pc (it uses functions to read a file), yet it calls a function in the xc file(fl_connect) which must run on the device.
So how can a pc host program call an xc function?
Or does the programmer.c run on the device and can make system calls thru the debug adapter?
Here's the link to the repo: https://github.com/xcore/sw_flashlib_examples
app_factory_image_programmer questions
-
- Experienced Member
- Posts: 94
- Joined: Sun Feb 10, 2013 4:47 am
-
- Experienced Member
- Posts: 74
- Joined: Mon Dec 16, 2013 12:14 pm
The source filesprogrammer.c and flash_connect.xc are compiled into an xe file that runs on the xCORE device. System calls are then made thru the debug adapter to read the firmware file.
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
I found Xmos system call interface which maybe useful, there are also some application notes that can be found using google eg AN10123
regards
Al
regards
Al
-
- Experienced Member
- Posts: 94
- Joined: Sun Feb 10, 2013 4:47 am
Very interesting.
What has to be running on the pc side for this to work?
xgdb? xflash? xrun?
What has to be running on the pc side for this to work?
xgdb? xflash? xrun?
-
- XCore Legend
- Posts: 1274
- Joined: Thu Dec 10, 2009 10:20 pm
I guess xrun as this handles things like io buffering/xscope etc.. however it also tends to call on xgdb underneath for debugging purposes.
-
- Experienced Member
- Posts: 94
- Joined: Sun Feb 10, 2013 4:47 am
I was able to get this working, but reading the firmware file from the host is very slow.
It seems about 20 times slower then DFU update via usb.
So unless it can be sped up, it's impractical as a factory programmer.
It seems about 20 times slower then DFU update via usb.
So unless it can be sped up, it's impractical as a factory programmer.