The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I'm on a quest to create my own "custom" Netduino board. Meaning I want to design a PCB which uses the same microcontroller (STM32F405RGT6) as the Netduino Plus 2 does, and which accepts the standard Netduino Plus 2 firmware.
The reason for wanting to use the standard firmware is that tweaking the firmware too would be a little too much to wrap my head around for now.
I'm reading the schematics for the Netduino Plus 2, and have some questions.
Is it correct that in order to use the standard firmware I need to use an external 25MHz oscillator? And is it also true that the oscillator needs to have two capacitors with the same pF capacitance as the crystal has?
On the VDD inputs I see that there are 5pcs 0.1uF caps, and 3pcs 10uF caps. Why are there several of them, and how to you determine how many?
Yes you need to use a 25mhz crystal to use the netduino firmware
The crystal needs 2 load capacitors and for optimal results you need to take into consideration the boards parasitic capacitance to get the correct values for the 2 caps. You can probably get away with using the same values as stated on the crystals datasheet.
Each VCC pin should have a 0.1uF decoupling cap and a few 10uF to smooth things out
Have a look at the description in the datasheet, it explains it in great detail.
When BOOT0 is logic 0, the code executes from flash - this is what you want for 'normal' operation, i.e. .NET MF running; the pull-down resistor R12D ensures the logic 0 level,
When BOOT0 is logic 1 (switch pressed) then BOOT1 determines if the code executes from system memory (logic 0, ROM Bootloader), or embedded SRAM (logic 1). You usually want the ROM bootloader to be executed, hence the second pull-down resistor R11D. BOOT0 is a dedicated pin, while BOOT1 is shared with GPIO (PB2) - it is sampled a few cycles after reset, then it can be used as regular GPIO.
The use of the rest of bootloader pull-up/down resistors is described in the Application Note 2606: basically, when a peripheral (USART, CAN, USB) is used to connect to the bootloader, its "pins have to be kept at a high or low level and must not be left floating during the detection phase".
Thanks CW2, I'll take a look at that Application Note.
The sheer volume of information and documentation in those datasheets and appplication notes can be quite overwhelming, so I appreciate your comments.
One other question - I'm creating a Fritzing part for the STM32F405RTG6, and I have a question about the naming of the pins. I see that the Netduino schematics includes more information than just the name of the pin. For example, pin "PA2" is called "PA2/UART2_TX". Is that the pin-configuration that just the Netduino firmware uses, so that when I create the Fritzing part I should name the pins with the shortname?
For example, pin "PA2" is called "PA2/UART2_TX". Is that the pin-configuration that just the Netduino firmware uses, so that when I create the Fritzing part I should name the pins with the shortname?
That pin configuration is microcontroller-specific. It means the GPIO pin is shared (multiplexed) with another peripheral - it can be configured as third pin of GPIO port A, or TX line of UART2. There is a big table in the datasheet that describes pin functions - most pins have more than one features (I think theoretically up to 15 in ST micros) and sometimes the same signal can be enabled on different pins (e.g. UART2 TX is available also on PD5).
Regarding the names in schematic symbols, it depends - you'd probably need to include at least the GPIO identifier and maybe the alternate function when it is important in your design - like in the above example, "PA2/UART2_TX" indicates the use of TX serial line. Listing all the available features on each pin would require quite large symbol, but I have seen such schematics too (usually, the part is split into several symbols that contain logically grouped features). I think in Fritzing, you can have additional information in the pin description, which is displayed in form of tooltip...
You mean the firmware found at https://ghiopensource.codeplex.com ? For now I'm not comfortable compiling my own firmware, so I'll try to create a board that works with the Netduino firmware instead. Maybe, when I have that working, I can have a go at creating custom firmware.