XUF232-1024 stalls after software reboot

[VHEMaster]

Hi everyone.

Chip is XUF232-1024-FB374-C40 as tile[0-3] and second XU208-256-TQ64-C10 as tile[4]

I'm stuck with software reboot issue. The reboot code, which executes on tile[0], was taken from module_usb_audio for this chip and previously was used for device reboot to enter into DFU mode.

Code: Select all

void device_reboot_aux(void)
{
    unsigned int pllVal;
    unsigned int localTileId = get_local_tile_id();
    unsigned int tileId;
    unsigned int tileArrayLength;

    /* Find size of tile array - note in future tools versions this will be available from platform.h */
    asm volatile ("ldc %0, tile.globound":"=r"(tileArrayLength));

    tileId = get_tile_id(tile[4]);

    read_sswitch_reg(tileId, 6, pllVal);
    pllVal &= PLL_MASK;
    write_sswitch_reg_no_ack(tileId, 6, pllVal);

    wait_us_reboot(3000);

    tileId = get_tile_id(tile[3]);
    read_sswitch_reg(tileId, 6, pllVal);
    pllVal &= PLL_MASK;
    write_sswitch_reg_no_ack(tileId, 6, pllVal);

    read_sswitch_reg(localTileId, 6, pllVal);
    pllVal &= PLL_MASK;
    write_sswitch_reg_no_ack(localTileId, 6, pllVal);
}

We have two devices and on the first one it works perfectly, but the second one can stall at 10th-20th reboot.
The device resets for sure, but stalls for unknown reason. It can be seen by probing QSPI CLK pin X0D10

Here you can see CLK signals when device boots up normally.

a3164ec4-7809-48fa-aa5e-ccba6b3fd0ad.jpg

But here device stalls. In that case only hard reset or power reset helps.

0976f0b6-a18d-4c62-9e2e-62fcb3ae51a0.jpg

Please help. Best regards

[bearcat]

Sounds like an occasional timing issue, since it works most of the time. From the SPI, looks like tile[0] gets loaded correctly, but does not succeed to tile[4] over the xlink. Maybe:

1 - Increase the 3000uS delay longer.
2 - Slow down, if workable, the XLINK in your .XN file between the two chips.
3 - Use latest XTOOLS (not saying version 15, per se). Boot code keeps improving.
4 - Could the XLINK be blocked sometimes??

You can attach the debugger to the running process on a bad reboot and see what the code is doing on each tile.

Edit: tile[4]

[VHEMaster]

bearcat, thanks for answer!

1 - Increase the 3000uS delay longer.

Increasing delay up to 10ms didn't work, as well as adding additional delay between last two reboot sections.

2 - Slow down, if workable, the XLINK in your .XN file between the two chips.

Increasing delays up to 4 times didn't work

3 - Use latest XTOOLS (not saying version 15, per se). Boot code keeps improving.

15.1.0 vs 14.4.1 didn't work either

4 - Could the XLINK be blocked sometimes??

It is nothing else on this XLINK, if I got you right...

Also there is another problem: it is another USB Device port on tile[4] and after exceeding some firmware size like adding/removing functionality it stops working correctly on some devices with the same configuration :\ Something similar was described in my previous topic: https://www.xcore.com/viewtopic.php?f=7&t=8072
Previously it was fixed by removing UART functionality by releasing a core from tile[4], but as well as main's chip (tiles[0..3]) functionality became larger it stopped to work again.

[mon2]

USB as can be expected, is a very time critical IP. It can be broken easily with blocking code.

Can you test the XU208 with a simple LED blink flasher and confirm it is solid before debugging your USB IP?

There are tools inside the xtimecomposer to offer a graphical view of how your cores spend their time. That view will assist you to confirm if the bandwidth is suitable to run the USB IP or not.

On the boot over xlinks, are you confident the issue is not hardware related? Soldered properly? Power sequence us being followed? Ample current for each power rail?

If the 2 devices are not close to each other, then lvds transceivers should be used for the xlinks.

Post the related schematics to review the interconnects and power rails, sequencers.

[VHEMaster]

Hi, mon2. Thanks for answer

USB as can be expected, is a very time critical IP. It can be broken easily with blocking code.
Can you test the XU208 with a simple LED blink flasher and confirm it is solid before debugging your USB IP?

User app doesn't even boots before the device stalls :( Also, at the very beginning the user app has a single core used on tile[4] to give a signal to external device, and only after that is boots other USB related cores.

On the boot over xlinks, are you confident the issue is not hardware related? Soldered properly? Power sequence us being followed? Ample current for each power rail?

Yes, everything as expected. Especially, considering that hardware reboot or power reset boots the chip fine. Only SW reboot issue presents.

If the 2 devices are not close to each other, then lvds transceivers should be used for the xlinks.

I couldn't find any information about the rules of PCB routing of XLINK bus. Do you know one? It is 3.2mm between minimum and maximum length of the tracks, and the average track's length is 85mm.

[mon2]

See attached.

https://www.xmos.ai/file/an01024-xconne ... n-demo-sw/

AN01024_-xCONNECT-dynamic-configuration-demo_1.0.1rc1.pdf