Pi 400, WiFi HAT and RISC OS 5.29

Nice clean install of RISC OS 5.29 (29th Nov 2020 nightly) on a Pi 400, new HardDisc4, latest Elesar WiFi HAT driver installed, but having no success. The driver is installed correctly but it’s not showing up in Interfaces, nor is the WiFi Manager loading to the icon bar. Before I start rolling things back to figure out where the problem is, has anyone else tried the same setup?

Not sure if i remember this right but i think the gpio is flipped on the pi400
maybe the cable is upside down

The WiFi HAT works here on the RPi400. Plugging the HAT in is a bit fiddly to avoid being a “pin out”.

Works without problems here. Have plugged it direct to the Pi400 expansionsport.

The WiFi HAT works here on the RPi400. Plugging the HAT in is a bit fiddly to avoid being a “pin out”.

I’m assuming the WiFi manager would still load, though, even without the hardware.

I’ve tried everything I can think of – files are all where I’d expect them to be in !Boot and I can see the EtherWILC file. Very strange. I guess I’ll just start from scratch again. Or go back to my Pi 4 where it is definitely working fine.

I’m assuming the WiFi manager would still load, though, even without the hardware.

Correct, though it doesn’t do much other than take up icon bar space if there’s no hardware.

I’ve tried everything I can think of – files are all where I’d expect them to be in !Boot and I can see the EtherWILC file.

Try the command *EWITest, it’ll tell you the result of the power on self test, including whether the HAT was detected at all. Note that the SPI bus clock in the Pi is derived from some of the other clocks, so if you’re trying to overclock the CPU that may result in the bus being too fast for the WiFi chip.

Hi Rob, I appreciate your answer and I’m not intending to ignore it, I’ve just been too busy with the Archive Dec/Jan issue to properly explore. I did run *EWITest, as suggested, but the command wasn’t recognised, which again suggests the driver and WiFi Manager aren’t loaded, rather than a hardware problem. Obviously the fault is with something I have done as other people have it working fine. I will experiment further soon. Thanks again.

As David says…

Plugging the HAT in is a bit fiddly to avoid being a “pin out”.

There is “a lot” of space around the plug…

… my first attempt was also not successful but if you find the right place, it should work.

What you need is one of these. The Flat HAT Hacker from Pimoroni,

I’m now having the same problem with a clean install 5.28 on a Pi 4 as Gavin was originally having.

*EWItest gives "File “EWITest” not found" but using *iicdevices, I can see the built in RTC. I’m not getting a power light on the HAT, but all the relevant software bits are in place.

Doulble clicking on EtherWILC in System.350 gives “unsupported hardware configuration”

Plugging the card into an older install and it just works, otherwise I’d be inclinded to go for a duff HAT.

Makes no sense… so, to quote Toyah… “It’th A Mythtery”..

*EWItest gives “File “EWITest” not found” but using *iicdevices, I can see the built in RTC. I’m not getting a power light on the HAT, but all the relevant software bits are in place.

Combined with the working status with 5.28 it has all the hallmarks of the GPIO pins being driven differently by the current install.

What happens if you softload the old GPIO module?

to quote Toyah… “It’th A Mythtery”..

Other items available. She and Fripp have been doing quirk video items at weekends, through the pandemic period.
Fripp in jail cell and Toyah with whips and leather.

Happy Sunday Lunch!

Ah, following up on what Steve said…

When I do a *ROMmodules, it says that GPIO 1.00 is dormant and when I try to RMReinit it, it says “Unsupported hardware configuration.”

Off to watch some YouTube videos…

Softloading it in PreDesk stops any network driver from being loaded! Double clicking it gives: Internal Error: abort on instruction fetch at &1FFD6C64 which is in Application memory

Smells like Teen Spirit is a peculiar one.

Tried an older ROM for a known working Pi setup and on this Pi, it displays the same issue – GPIO is dormant, but on the other Pi, it loads as active. Have the Pi Foundation changed something?

GPIO is dormant

There is a “garden path” here. GPIO 1.00 is Active here on this RPi400 with a fully working WiFi HAT.

A quick try of the ‘pin out’ syndrome, in both directions, did not result in GPIO being dormant.

I don’t have the RTC on my WiFi HAT.

To verify that the HAT is accurately inserted see Raik’s photo above. The HAT edge is almost right up to the edge of the SD card. Fortunately in a brilliant example of pre-emptive design the WiFi HAT corners are rounded so the SD card can be accessed with the HAT present.

HTH.

Have the Pi Foundation changed something?

There’s not much required to end up with a valid GPIO device (which is what the GPIO module is looking for), other than a known board revision. Are both your candidates running the same firmware (by which I mean the stuff in the EEPROM, not the stuff on the SD card)?

Maybe list the board revision on both, just in case the Pi Foundation changed the numbering scheme:

DIM block 64
block!0=64
block!4=0
block!8=&10002:REM GetBoardModel
block!12=4
block!16=0
block!20=0
block!24=0:REM End
:
SYS"BCMSupport_SendTempPropertyBuffer",block,block,0
:
PRINT~block!20

Non-working board is B03114
Working board is C03112

Hope that helps!

Updated the eeprom firmware to the latest one. Also updated fixup4.dat and start4.elf. The module is still dormant on B03114

The 8GB Pi I just tried, which worked first time, is D03114

I’m a bit confused – B03114, C03112, D03114 are all Model 4B’s, whereas earlier

I’m now having the same problem with a clean install 5.28 on a Pi 4 as Gavin was originally having.

which (as the thread title says) I’d interpreted as being about a Pi 400. Nevertheless, the problem seems to be that you’ve got your hands on some rev 1.4 boards but that are only fitted with 4GB or 2GB, and (certainly 5.28’s) lookup tables only know about 8GB rev 1.4’s. You’ll need to either get a rev 1.2 or 1.1 board, or use the 8GB for instant gratification, or wait a bit until the OS gets updated with entries for those newer revisions.

the problem seems to be that you’ve got your hands on some rev 1.4 boards but that are only fitted with 4GB or 2GB

Yes, I have a suspicion they were almost straight from the factory.

I thought I’d join in on Gavin’s thread as I knew it was perplexing him, and it may be useful to note that it’s now happening on Pi4s as well as Pi400s.

My board is a C03130… Pi400 with German keyboard layout.
I use the HAT without RTC.

I thought I’d join in on Gavin’s thread as I knew it was perplexing him, and it may be useful to note that it’s now happening on Pi4s as well as Pi400s.

The only published revision code for a Pi 400 is C03130 (as Raik confirms, this is independent of what’s printed on the keytops) and RISC OS 5.29 (since 6th Nov) knows about that, and Gavin mentions using 29th Nov, so whatever is odd about Gavin’s setup must be something else.

He could run that bit of BASIC I posted yesterday and check C03130 is the answer I suppose.

He could run that bit of BASIC I posted yesterday and check C03130 is the answer I suppose.

Thanks. My Pi 400 is indeed a C03130.

Today, I tried the RISC OS Pi 5.28 build from 16h December 2020. I have the same issues and they appear to be twofold, the hardware and the software.

1. The driver and WiFi Manager don’t appear to be loaded. The files are in the right places in !Boot but nothing is on the icon bar. Double-clicking on EtherWILC in !System.350.Modules.Network gives me “Hardware dependency not met”. FWIW, GPIO 1.0.0 is active, not dormant.
2. I am confident I am not a pin out but there is no activity from the LEDs at all. I’m starting to feel like I’ve killed the HAT somewhere along the way.

Surely 1 and 2 aren’t related because the WiFi Manager etc would still load, even without the HAT. And surely there would be some LED activity regardless of drivers. So, I’m still at a loss.

Surely 1 and 2 aren’t related because the WiFi Manager etc would still load, even without the HAT. And surely there would be some LED activity regardless of drivers. So, I’m still at a loss.

The driver queries the ID EEPROM on the HAT to first check that it’s the right one – all kinds of havoc could happen if you’d plugged some other HAT in and it starts changing GPIO settings! If the ID EEPROM doesn’t say it’s a WiFi HAT then the hardware dependency (on EtherWILC) is not met, and the driver refuses to load.

Do you have any other Pi boards to hand that you can try on? HATs, like cats, have 9 lives so contact Elesar support if think you might have killed it.