Hi Gurus,
My Cerbuino seems like it may of died. I’ve email the GHI dudes but I thought I would ask here in case it’s a simple fault that’s easily rectified.
Last night I was trying out the RLPlite example (with just a bare Cerbuino) and the debug process appeared to freeze in VS (I don’t remember at exactly what stage). I left it for five minutes but in the end I had to disconnect the USB to be able to continue in VS, then I got the check your hardware message. Upon reconnecting the Cerbuino by USB, windows says that it does not recognise the USB device. I tried setting the jumper to load firmware but it’s still the same.
A colleague of mine, who I suggested try the GHI stuff for his projects, said he had a Cerbuino do the same thing but just bought another one because he had to get the project finished.
Has anyone here had anything like this? I’ve ordered another one but it’s a bit of a weird coincidence. I’ve had it for months and it’s been fine. Could it of got stuck in the realms of between programs?
Many thanks
You can try to use the Dfuse utility to erase the chip completely and load the firmware. Look at this page
https://www.ghielectronics.com/docs/55/loader-tinybooter-update-fez-cerberus
Or try FezConfig.
Because it’s not a recognised USB device in windows, it doesn’t show up in DfuSe. I haven’t tried FezConfig yet but my guess is that it would be the same.
Would it be possible to get it going over UART?
I would try different USB port or even a different computer to be sure.
Yeah, that was the first thing that I tried. Still no dice.
I’m a bit surprised there’s no reply from GHI guys.
Please post the C# code you used as a test program to load and call your RLPLite routine(s)
Per the instructions starting at https://www.ghielectronics.com/docs/55/loader-tinybooter-update-fez-cerberus#539 put the Cerbuino in boot mode and reset. Take a look at Devices and Printers In Windows’ Control Panel. Do you see STM32 BOOTLOADER? (If at all possible, attach a screen shot of the Devices and Printers window)
I am sure that you have tried this, however small things could be missed
To enter DFU mode ensure that BOOT0 is high and BOOT1 (PB2) low during reset.
You can try DFU over UART using
USART1(PA9/PA10)
USART3(PB10/11 and PC10/11)
Looks like persistence has paid off! 
After a couple of tries it went into DFU mode and has taken tinybooter and the firmware. Now showing in device manager as ‘GHI NETMF debug interface’
Is it possible that I have done something wrong with my RLPlite project and corrupted memory or something? I’ll post the code later for you guys to muse over.
Many thanks.
Had a go at sorting out my colleague’s Bee as well and that has now come back to life. I suspect he didn’t really try. 
Anyway, before I did anything, I checked the status in the STDFU tester and got the message attached in the screenshot.
Does that mean anything to anyone?
OK, I have some answers to my troubles now. My attempts at following the RLPlite guide (it’s missing loads of information by the way) have landed me in this problem, as I’ve discovered that getting the memory address spaces wrong can cause the firmware to crash.
What I don’t get though is that the guide, and the cerb family docs, clearly state that the RLP regions are;
[quote]For the Ethernet firmware, the region is 12KB (0x3000) and begins at address 0x2001A000.
For the Non Ethernet firmware, the region is 8KB (0x2000) and begins at address 0x20000000.[/quote]
Yet I’m definitely using the non ethernet firmware (checked it twice) and can only get it to work by using 0x2001A000 as the R/O base and 0x2001C000 as the R/W base, as per an RLPlite project for the Bee that I found in the codeshare.
So would anyone be able, and kind enough, to explain this for me?
@ wolfbuddy - 2 questions for you:
-
What version firmware are you running?
-
What information is the RLP Guide missing?
1 -
[quote]HalSystemInfo.halVersion: 4.2.0.0
HalSystemInfo.halVendorInfo: Copyright GHI Electronics, LLC
HalSystemInfo.oemCode: 255
HalSystemInfo.modelCode: 255
HalSystemInfo.skuCode: 65535
HalSystemInfo.moduleSerialNumber: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
HalSystemInfo.systemSerialNumber: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ClrInfo.clrVersion: 4.2.0.0
ClrInfo.clrVendorInfo: Copyright GHI Electronics, LLC
ClrInfo.targetFrameworkVersion: 4.2.0.0
SolutionReleaseInfo.solutionVersion: 4.2.5.0
SolutionReleaseInfo.solutionVendorInfo: Copyright © GHI Electronics, LLC
SoftwareVersion.BuildDate: Apr 25 2013
SoftwareVersion.CompilerVersion: 410713
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False
[/quote]
2 - I had to add some files to the uVision project to be able to compile it (system_stm32f4xx.c and startup_stm32f40xx.s). Only after checking out some stuff posted in the codeshare was I able to find this out. Even then it took me a while to find the right files! I did install uVision 5 though so maybe there’s a difference with uVision 4 projects?
You also have to select the correct CPU. The guide isn’t very specific about this for other boards and I’ve seen some other posts in the forum asking about it. Some more details would be helpful there.
And then the memory allocation problems cost me a lot of time.
Bear in mind I’m a total noob at this so that could explain it all! :-[
Edit; I see there’s a newer firmware version than I’m using. I’ll update and test.
Quick update then.
It seems the RLP address spaces have changed with the firmware, it’s now happy with the R/O as 0x20000000 and R/W as 0x20001000.
