We bought some G400-D modules. When we received them, the version of TinyBooter was 4.2 and the TinyCLR one was 4.2.
First, on our computer, we installed the .Net Micro Framework SDK 4.3 following the instructions on your website. Secondly, we upgrade the TinyBooter and the TinyCLR both to 4.3 version.
After that, we started developing a small test application and deploying them on the SOM via USB. At the beginning (for the first 2-3 times), we hadn’t problems in deploying; then, unfortunately, we were no longer able to communicate with the SOM, neither with Visual Studio, neither with FEZConfig and other GHI Tools.
The problem is that that situation is the same for all boards we bought, even thought we tried to deploy the app from another pc, and also via Serial communication.
Are we making some mistakes or are there unknown bugs in the new bootloader-firmware (4.3)?
How can we reset the boards? We wouldn’t like to waste them (which would mean wasting almost 500$…)
Is there someone that had had the same issue? Could someone help me?
It’s urgent, beause we are stuck with the design of new products.
Any suggestion will be appreciated.
the community will help out here for sure, you won’t have wasted your money.
First up, a common cause of this kind of behavior is actually your application. Its possible that you have deployed something that doesn’t let the debugging engine running on the device to communicate to your PC. If this is the case, by booting into the bootloader and reflashing the firmware you usually get back to a “vanilla” point where you can get access to the device again.
The other thing to talk about is how you’re using the G400D - in particular, do you have the G400DHDR or have you designed your own holder / circuit ? And if your own did you connect via USB for deploying the code, or just through serial ?
After a few attemps, maybe we figured out that the problem is the insufficient power supply, due to the only USB power supply.
After connecting an external source, we managed to reset all boards tinybooter and tinyclr…
Now, we have still just a problem… we can’t enter in the loader mode, although the deploy seems to work fine up to now.
The G400 is mounted on the G400DHDR; when we try to enter in the loader mode (following the instructions), the display (GHI T43 module, connected to the HDR) freezes (in some cases it becames all white, in some other cases black with some vertical rows…) and it doesn’t display the typical infos about tinybooter versione, build date… as it did before the “power supply issue”.
Tomorrow I will do more tests and I will provide you some photos if they are needed.
I’d suggest removing the display while you work out power capacities and sources. You can still enter loader mode without the screen - and by focusing on what device appears in device manager you’ll know what state the device is in
I just tried what you suggested.
In both tinybooter and tinyclr the device that appears in the device manager is always the same (see the picture attached)…
with 2 boards of 5, by pressing the LDR1 (in HDR breakout board) at the power-up, the tinybooter mode starts correctly, whereas with the others 3, it happens what I told you yet.
With all boards:
[ul]the G400, either in TinyBooter either in TinyCLR, appears in device manager like in the picture of the previous post.[/ul][ul] when I ground PA11, the device appears correctly as a COM port… and that’s ok.[/ul]
I can’t understand why I should ground PA11 to get those 3 boards to boot in TinyBooter mode, whereas with the other ones it’s not necessary.
I would check you have the same firmware loaded on them all - I can’t explain what you’re seeing. PA11 is the method documented in the manual so I would continue with using that to get to a level playing field.
so let me reiterate - you applied new bootloader and netmf firmware to all boards, from the same PC. You haven’t deployed code to them. But you still see different behavior in them ?
