Hi David,

nothing immediately comes to mind, sorry. We have not encountered this to
our knowledge, and it seems like it's hard to trigger in the first place.

--M

On Wed, Sep 10, 2025 at 6:11 PM David Raeman via USRP-users <
[email protected]> wrote:

> Hello,
>
>
>
> I sometimes use USRP E320 radios in unattended collection systems with the
> autoboot feature enabled. I’m aware that the shipped firmware did not
> originally support the autoboot flag, and these radios have updated
> firmware flashed in early 2024 (RO and RW are both neon_v1.1.7358-a190641).
>
>
>
> What I notice is that autoboot almost always works, but on rare occasion
> it fails to boot when power is applied. Anecdotally, the failure seems much
> more likely if the E320 hasn’t been powered in a long time (months). It’s
> almost always fine if I’ve used the radio in the past few days. Recently I
> was able to catch it occur while monitoring the STM32 console:
>
>
>
> --- UART initialized after reboot ---
>
> [Reset cause: reset-pin power-on]
>
> [Image: RO, neon_v1.1.7358-a190641 2019-10-11 15:41:40 @b6fa67df8407]
>
> [0.000359 Inits done]
>
> [0.034868 SW 0x03]
>
> Enclosure version ... using alternative thermal parameters
>
> Console is enabled; type HELP for help.
>
> > [0.045631 power state 4 = G3->S5, in 0x0000]
>
> [0.045802 power state 1 = S5, in 0x0000]
>
> [0.045942 power state 5 = S5->S3, in 0x0000]
>
> [0.046128 event set 0x00002000]
>
> [0.046246 hostcmd init 0x2000]
>
> [0.060178 power state 2 = S3, in 0x0002]
>
> [0.074411 power state 6 = S3->S0, in 0x01fe]
>
> [0.311983 power button released]
>
> [0.312175 SW 0x01]
>
> [1.074642 AP didn't come up, shutdown]
>
> [1.074810 power state 7 = S0->S3, in 0x01fe]
>
> [1.090703 Watchdog timeout, ignored]
>
> [1.106994 power state 2 = S3, in 0x0002]
>
> [1.107180 power state 8 = S3->S5, in 0x0002]
>
> [1.107397 power state 1 = S5, in 0x0000]
>
> [1.107548 power state 9 = S5->G3, in 0x0000]
>
> [1.107709 power state 0 = G3, in 0x0000]
>
>
>
> There is no further output. The “sysinfo” command shows that the STM32 is
> still running the RO firmware and hasn’t jumped. From here, if I run
> “powerbtn 1000” or press the physical button, it will fail again. Then if I
> do it a second time, it always works - the Zynq comes up and everything is
> good:
>
>
>
> > powerbtn 1000
>
> Simulating 1000 ms power button press.
>
> [549.731435 power button pressed]
>
> [549.731588 power button is pressed]
>
> [549.731755 power state 4 = G3->S5, in 0x0000]
>
> [549.731947 power state 1 = S5, in 0x0000]
>
> [549.732131 power state 5 = S5->S3, in 0x0000]
>
> [549.732434 SW 0x03]
>
> [549.732565 event set 0x00000004]
>
> [549.746562 power state 2 = S3, in 0x0002]
>
> [549.760907 power state 6 = S3->S0, in 0x01fe]
>
> Simulating power button release.
>
> > [550.731581 power button released]
>
> [550.731780 SW 0x01]
>
> [550.761149 AP didn't come up, shutdown]
>
> [550.761350 power state 7 = S0->S3, in 0x01fe]
>
> [550.777265 Watchdog timeout, ignored]
>
> [550.793740 power state 2 = S3, in 0x0002]
>
> [550.793958 power state 8 = S3->S5, in 0x0002]
>
> [550.794208 power state 1 = S5, in 0x0000]
>
> [550.794392 power state 9 = S5->G3, in 0x0000]
>
> [550.794585 power state 0 = G3, in 0x0000]
>
>
>
> > powerbtn 1000
>
> Simulating 1000 ms power button press.
>
> [644.821458 power button pressed]
>
> [644.821612 power button is pressed]
>
> [644.821779 power state 4 = G3->S5, in 0x0000]
>
> [644.821972 power state 1 = S5, in 0x0000]
>
> [644.822156 power state 5 = S5->S3, in 0x0000]
>
> [644.822459 SW 0x03]
>
> [644.836578 power state 2 = S3, in 0x0002]
>
> [644.850931 power state 6 = S3->S0, in 0x01fe]
>
> Simulating power button release.
>
> > [645.821604 power button released]
>
> [645.821804 SW 0x01]
>
> [645.845928 power state 3 = S0, in 0x01ff]
>
> [645.846349 HC 0x01]
>
> [645.847056 HC 0x02]
>
> [645.849352 HC 0x9e]
>
> +++(++)[649.114626 HC 0x02]
>
> [649.116925 HC 0x16]
>
> [649.117941 HC 0x11]
>
> +++(++)[650.450201 HC 0xd2]
>
> [650.450414 Executing host reboot command 2]
>
> [650.450709 Jumping to image RW]
>
> [650.459254 UART initialized after sysjump]
>
> [Image: RW, neon_v1.1.7358-a190641b3 2019-10-11 15:41:40 a@xaphan]
>
> …
>
>
>
> I’d like to rely on the autoboot feature without console intervention, and
> at some point I’ll probably trace through the STM32 logic, but I’m hoping
> the knowledgeable folks at NI/Ettus might have a quicker solution..
>
>
>
> Thank you,
>
> David Raeman
>
>
> _______________________________________________
> USRP-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to