I just posted Fix G400 TInyBooter update procedure on Task Tracker. Feel free to discuss and make suggestions here.
1 Like
@ Simon from Vilnius - What specific devices prevent the G400 from being updated when connected? More specifically, which pins and how are they driven?
Just driving PA11 low, as per obsolete instructions.
Will send you a personal message for details…
@ Simon from Vilnius - LDR0 and LDR1 will be implemented.
There is nothing we can do from a software standpoint for PA11. It must never be driven during power up. You are likely seeing the unknown device because PA11 is not released.
Once we implement LDR0 and LDR1, PA11 will no longer be needed to update TinyBooter, but even then it must not be driven.
Where is PA11 on G400D?
@ leforban - PA11 is part of SPI1. In the G400D brochure, these pins are marked as SPI-use only (pins 107-109), so we do not label the pin as PA11. I will look into clarifying in the documentation that PA11 should not be driven. Additionally, the other two SPI1 pins should not be driven as well.
Huh? How am I supposed to update the “never-changing” Tinybooter on G400 if I don’t pull PA11 low on boot-up?
@ Simon from Vilnius - Sorry, I was unclear. Once we implement LDR0 and LDR1, PA11 will not be needed to update TinyBooter. Until then, continue pulling it low only to update TinyBooter.
I have never work with SPI before but plan to connect an LCD screen or other peripherals on it soon. Does this mean this won’t be possible?
@ John - Oh, ok. Waiting for new SDK then 
LDR0 and LDR1 is coming, yeah!
I am using the other one as standard GPIO…the question is may I have an SPI module connected to SPI1 without losing update ability.
@ leforban - You will need to remove the module to update TinyBooter, but other wise it will work fine.
pffff please update your documentation and give clear explanations on all needed processes…
These pins are now reserved in my design to connect SPI peripherals in the future. I don’t know what will be connected. But for sure removing the peripheral to let the board start properly is not a normal way to start a device Even if it’s just to update the board. This information should be known since a lot of time. I do not consider normal to have this information so late!
II already spent a lot of time to draw schematics and route the PCB. It’s an entire week just to route the board…
I am supposed to launch pcb production at the end of next week! This won’t be possible now due to a poor documentation. I am not hobbyst, I need reliable documentations to make design choice.
G400 is sell since a year but still have a “preliminary” version of documentation this is not good for business…
@ leforban - I think there is misunderstanding from your end and John’s. Let me discuss this with the team and then we well get back to you.
Let’s wait and see.
@ Simon from Vilnius and @ leforban - while waiting fro the turkey to get ready, I had a minute to take a look at the documentation and I am not seeing any concerns.
For start, LDR pins have nothing to do with the SPI1. So the original post form Simon is not correct. SPI1 is needed by the system all the time, it is DATAFLASH internally. You can’t at any given time use these pins for anything but SPI and even when you use them as SPI, you have to consider that this bus is shared. Same rules applies to any SPI bus that is shared between multiple slaves.
So as for the “setting PA11 low will prevent the system from working”, yes this is true but why would this ever be the case? This pin is not a GPIO, it is a SPI pin, MISO to be exact. Therefore, if the slave (whatever you have connected) should not touch this pin unless it is “selected” using SSEL pin, sometimes called CS for chip select.
As for John’s comment on “remove the module to update”, I do not understand why and I will discuss with John tomorrow. But your design is G400 system, not Gadgeteer, so there is no “module” to be removed.
Everything I said above is already explained in the manual under “design consideration”
To reiterate on this, the LDR pin state has nothing to do with this. SPI is shared and rules apply like any other system when SPI is shared.
…back to check on the turkey Happy thanksgiving everyone.
@ Gus - my post was 100% correct.
Currently, the only way to update G400 TinyBooter is to pull PA11 low on bootup (I don’t use it for anything else that is not an SPI), but when I do that in production board, Windows gives me a [em]“USB device not recognized” baloon[/em], and I can’t update TinyBooter. Apparently, since that is a production board, peripheral connections must be interfering somehow. So the only way to update TinyBooter for me now is to pull G400D module (nothing to do with Gadgeteer modules) out of production PCB and put it in a naked G400HDR board, where the TinyBooter update procedure works fine.
I have routed LDR0 and LDR1 pins out for future TinyBooter updates, but as of now they are still not functional, so PA11 and G400HDR board is the only way.
I remember having the same problems with Raptor board, decorated with various GHI modules, but, unfortunately, I cannot recall what was the configuration exactly. That’s why I suspect updating G400S’ TinyBooter might be an impossible task in productions systems.
Poor leforban, it’s really a bad time to enter G400 world Old documentation is marked obsolete, new one is confusing, and then there more changes coming with the next SDK that will change everything…
P.S. Was that a happy turkey that made you a happier person?
All is not that bad, It took me just a day or two to move my application from EMX to G400 and SDK4.2 to SDK4.3 and start debugging and tunning. As far as I can see this speed up my application by a decade and I am happy with that. I just need now to be sure on what is available and not available in terms of IO, update abilities, compliant peripherals and so many things… The plan was to be able to launch our new product in january. I still have space for modification but can’t wait for the next SDK that will change “everything”.
If details are precisely given and there’s no change it 's not a problem to route the PCB now.
For the moment SPI1 is only SPI and LDR0 and LDR1 are route as described in the documentation.
@ Simon from Vilnius - no need for sarcasm please. I am only trying to help and will continue trying to help! Also, the documentation was removed and replace with one document to make it easier for everyone, the user manual.
You are now talking about the other feature of PA11 (SPI MOSI), which holding it low on power up to trigger the processor’s SAM-BA software, which is the built in boot loader from the processor’s manufacture. If this did not work in your custom design, then there is something else. Do you have PA9 high, per user manual?
By the way. adding LDR pins in the future is a feature to improve the user’s experience but it is not needed. You should be able to do everything needed today. We may or may not be adding LDR in the future.
@ Gus - There was no sarcasm, don’t loose your sense of humor please.
PA9 is a CAN1 pin, why would I want to keep it high?