Automated testing environment on real hardware

[farcaller]

A bunch of rtos code is hard to test without real hardware (e.g. #194). Possible solution is to hook some board to CI (pyocd seem to be scriptable enough for that).

[bharrisau]

Agree. Though the first step is to endorse a platform. Do you have anything
in mind that is easy to get plus has the debugging broken out?
On 19/10/2014 4:45 pm, "Vladimir Pouzanov" notifications@github.com wrote:

A bunch of rtos code is hard to test without real hardware (e.g. #194
#194). Possible solution is to
hook some board to CI (pyocd seem to be scriptable enough for that).

—
Reply to this email directly or view it on GitHub
#195.

[farcaller]

There's VTOR thing in cortex-m3 to remap vector table to ram, so we can boot any chip from ram.

On hardware; pyOCD-supported board should be best as that one is scriptable in python (vs. scriptable in gdb which is harder).

[farcaller]

So far the test idea looks this way:

• each test gets linked into dedicated bin file where main() starts the test
• upon test end, it must issue bkpt and test state in r0

Test is successful if there's a breakpoint hit and r0 is 0 (caveat: abort() in zinc hits breakpoint too).
Test is failed on any other r0 value or timeout.

Should be simple to implement.

[bharrisau]

It would be nice if there was a dual chip reference board. One can be the
usb-debug interface the other the target.

Plus when you want to test the USB-host, you can have the second chip reset
and program the main chip, run the test, then reset back to normal.

It would be a nice dev board for high reliability stuff too.
On 19/10/2014 5:49 pm, "Vladimir Pouzanov" notifications@github.com wrote:

There's VTOR thing in cortex-m3 to remap vector table to ram, so we can
boot any chip from ram.

On hardware; pyOCD-supported board should be best as that one is
scriptable in python (vs. scriptable in gdb which is harder).

—
Reply to this email directly or view it on GitHub
#195 (comment).

[farcaller]

I have exactly that kind of board 😉

[bharrisau]

Can I buy one somewhere? Sounds like a good board to bless as a zinc
reference platform.
On 19/10/2014 5:57 pm, "Vladimir Pouzanov" notifications@github.com wrote:

I have exactly that kind of board [image: 😉]

—
Reply to this email directly or view it on GitHub
#195 (comment).

[farcaller]

http://developer.mbed.org/platforms/mbed-LPC1768/, it's not exactly cheap though.

[errordeveloper]

I think that's exactly what mbed guys use pyOCD for... Although, I'm wondering if qemu wouldn't be sufficient for this specific purpose?

[farcaller]

qemu would be a really good option, but cortex-m support in qemu is poor to non-existent.

[0xc0170]

@errordeveloper not exactly correct, but that's the main advantage of pyOCD. 😉

I'll be glad to help out.