XUF232-1024 stalls after software reboot

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
VHEMaster
Junior Member
Posts: 5
Joined: Wed Feb 03, 2021 1:15 pm

XUF232-1024 stalls after software reboot

Post by 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
You do not have the required permissions to view the files attached to this post.
bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

Post by 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
Junior Member
Posts: 5
Joined: Wed Feb 03, 2021 1:15 pm

Post by VHEMaster »

bearcat, thanks for answer!
bearcat wrote: Sat Aug 07, 2021 7:04 pm 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.
bearcat wrote: Sat Aug 07, 2021 7:04 pm 2 - Slow down, if workable, the XLINK in your .XN file between the two chips.
Increasing delays up to 4 times didn't work
bearcat wrote: Sat Aug 07, 2021 7:04 pm 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
bearcat wrote: Sat Aug 07, 2021 7:04 pm 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.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by 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
Junior Member
Posts: 5
Joined: Wed Feb 03, 2021 1:15 pm

Post by VHEMaster »

Hi, mon2. Thanks for answer
mon2 wrote: Wed Aug 18, 2021 12:28 pm 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.
mon2 wrote: Wed Aug 18, 2021 12:28 pm 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.
mon2 wrote: Wed Aug 18, 2021 12:28 pm 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.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

See attached.

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

AN01024_-xCONNECT-dynamic-configuration-demo_1.0.1rc1.pdf
You do not have the required permissions to view the files attached to this post.