You are comparing two .tar.gz files created on different machines and (presumably) different tar an gz programs (different versions and linked libraries).
If only one byte in the .tar.gz is different, you get different sha256 sums.
You have to compare the contents of the .tar.gz. files to check for differences.
there must be 100nF capacitors in the TX line. These are missing on the PicoCoreBBDSI.
Try the procedures described in WindowsCE First Steps
On Variants without a PHY (e.g. PicoCoreMX8MM-V1), are these signals routed directly to the respective connector pins with matching trace lengths?
-> Yes
Is there something important we have to consider when connecting an external switch/phy?
-> check voltages for the pins, some PHYs have different voltages for the MDIO interface and Reset/Interrupt
Do you have any reference designs or experience for connecting an external phy on the carrier board to a PicoCore?
-> the DDR3L variants of the PicoCore8MM have a 2 port switch on the board
Is it possible to run full speed a.k.a. 1Gbit this way?
-> Yes
Regarding the clock delay of 1.5-2ns needed by RGMII, this can either be done by the phy/mac devices itself (RGMII-ID) or in HW via trace lengths. I would guess the first method (RGMII-ID) is the simpler and more common one, correct?
-> Correct
Is there a big difference in connecting a device via RMII compared to RGMII, apart from the different signals? So in terms of trace lengths, delays, etc.
-> RMII is not critical, the clock is only 50MHz compared to 125MHz in RGMII. We have not tested RMII operation on the PicoCore 8MM.
The hareware documentation of the armStoneMX8MP is misleading on the UART_C and UART_D signals.
The RS232 signals RS_RXDCD and RS_TXDCD are either generated fom UART_C or from UART_D. This is configured during production.
Since the default is UART_C you can't use UART_C_TXD and UART_C_RXD on the feature connector.
UART_C_RXD is driven by the RS232 transceiver.
If you need the UART_C signals, contact sales@fs-net.de for available options.
If you use an external 3.3V supply, you have to make sure, that the voltage is not applied to the PicoCore pins during reset.
If voltage to the PicoCore pins is applied, then the processor is powered through this voltage.
You have to decouple the PicoCore from your 3.3V supply to get 0V.
the 3.3V voltage regulator on the base board is controlled by the 3.3V output of the PicoCore.
The PicoCore PMIC disables the 3.3V on the PicoCore during reset and the 3.3V on the base board is switched off.
But if voltage from the base board is fed back to the PicoCore, the 3.3V on the PicoCore never drop below the switching threshold of the voltage regulator and the 3.3V on the base board never switches off.
A possible solution could be to use a voltage divider on the EN pin of the voltage regulator.
Since the RT8070 needs 1.6V for enable, a resistor in the range of 150k could work.
The PMIC of the PicoCore disables the voltages at reset. Depending on the extenal wiring of the PicoCore it is possible, that current is fed back to the PicoCore from the baseboard. Then the voltage is never shut off completly.
You can send the schematic of your baseboard and a description of the desired behaviour to support@fs-net.de so we can have a look at it and can suggest a solution.
Is only one baseboard failing or all?
Is the failing PicoCore working in a known good baseboard?
Is a known good PicoCore working with a failing baseboard?
please provide the serial numbers of the working and failing components.
please provide the serial number of both base boards. The number is on the blue DataMatrix sticker.
The temperatures look OK for me.
Other customers have reported similar temperatures.
Which heat sink are you using? Only the heat speader or an additional heat sink?
Running the board without the heat spreader is not recommended.
A peak load can lead to a temperature above the throttling threshold an this results in a massive drop in performance.
The heat spreader distributes the heat away from the processor an the keeps the internal temperature below the threshold.
the armStoneA9r3 uses an external I2C RTC. 0.9-5.5V is the allowed input range for this chip.
We don't have a solution for a charging circuit.
The charging circuit depends on the power source you selected (rechargable batteries of different technologies, SuperCaps, etc.).
So ask the battery manufacturer for a solution for your battery.
See HW-Manual chapter 4.8 page 27/28.
You can use AUDIO_A or AUDIO_B interface.
AUDIO_A is only available if the audio codec is not installed.
AUDIO_B is 1.8V, so a level shifter is needed.
The audio format is configurable in software, so the modem should work with the PicoCore.
connection is as follows:
TXFS -> SPKR_WS
TXC -> SPKR_SCK
RXD0 -> SPKR_SD
TXD0 -> MIC_SD
Sorry, but we can't help with JTAG.
have you tried holding 's' during power-up?
If the board does not respond to the key then the nboot is not working.
For the PicoCOM series you need a special adapter to set it to recovery mode.
Please send the board back with RMA.
What exactly did you do? Which update tools were used?
Which files did you program?
You need to switch UART_A_RTS signal to the CLKREQ function in the device tree. Then this pin is routed to the PCIe function in the processor.
This pin is then no longer used by the UART.
