Reseting a PHY from U-boot - linux-device-driver

I am building a custom board that is based off of an existing evaluation module for a processor. On the evaluation module there is a MCU that handles most of the boot time configuration. Along with this, the MCU forces a reset on the PHY chips so that the PHY chips can begin communication. On my custom board there will not be an MCU to perform the reset and this the processor must perform the reset.
How would I go about performing the reset from u-boot?
My processor is connected to an SPI -> GPIO expander and this must reset the Phy through the use of SPI. I will not be performing an NFS boot so I do not need the Phys to be accessable from u-boot, but they do need to be reset before the Linux Kernel is booted in order for the kernel drivers to set it up correctly. Any ideas?

As per MII standards, your PHY chip will have basic mode control register at address 0x00. Look in PHY chip datasheet under 'PHY MDIO register Description'.
In U-Boot either phy-chip driver ( example marvell, vitesse etc.) if found, otherwise generic phy-driver will perform the phy reset.

Related

STM32H7 SPI frozen during break?

In order to freeze a timer during a break in debug mode on a STM32H7, one has to set a bit in the DBGMCU. But I didn't find such a bit for SPI. Does it mean that the SPI is always frozen ? Or on the contrary never frozen ?
Short answer:
There is no such option for the SPI. SPI is always enabled, if used and proper configured.
Long answer:
There is no such option for SPI because this interface must be either actively served by the microcontroller. In this case the SPI transaction is automaticly stoped if your device is halted e.g in break mode. Any ongoing transaction of a word/fifo will be executed anyway.
Or the dma controler is configured to server the SPI. In this case data transmission is controlled by the dma controller. The dma controller itself has different trigger sources. As long this trigger source is not a timer depended one there is no way to implicitly halt the transfer.
See also: https://stackoverflow.com/a/43225545/5388805

Watchpoint on STM32 GPIO register

using Keil µVision on a STM32F4 I am trying to add a watchpoint to a GPIO data register, which just does not trigger.
I want the watchpoint to be triggered as soon as output data gets writting into this register.
Setting the watchpoint to the os timer work fine.
Peripheral registers are memory mapped in STM32 F4, as far as I know.
Any (simple) explanation that I am missing here?
Any hint is very much appreciated.
While the ARM core can access the peripheral I/O registers in the same flat 32-bit address space as SRAM or flash, peripheral I/O registers are located in separate buses on the MCU, and not accessed by the same bus as the SRAM. For example, on the STM32F, there are the ABH bus which are usually further divided into the APB1 and APB2 buses, depending on the device. In any case, the debug controller unit defined by ARM ("CoreSight"), provides data watchpoint capability, and it only works on "real" data access.
Would be great if it did though ;-)
No source, or personal experience, but I can think of a few reasons why this wouldn't work.
Often value isn't "there" like in RAM, but is created when you access a peripheral register.
You could say periodic access could then solve this, but that wouldn't work for registers where reading has side effects (usually clearing some status flag).
I think you'll have to create an interrupt handler for GPIO, and a breakpoint for that.
there is a workaround if 12 cycles latency is a problem. Use Pin as a trigger which triggers memory to memory DMA transfer. Set the watchpoint on the destination (or source) RAM address.

ISP vs SPI: interpreting signal labels

I'm interested in interfacing an STM32-based flight controller with external sensors based on the SPI (Serial Peripheral Interface) protocol. I have a couple of FCs (Flip32 F3, shown in attached photo; EMAX Skyline 32) that have a section of pins marked 5V/GND/RST/SCK/MISO/MOSI, which I presume are there to support ISP (In-System Programming); i.e., these pins allow the FC to act as a slave device for a programmer device that acts as the master. Other boards, such as the multiFlite NANO-B-FC, provide pin headders explicitly for SPI (other attached image), with CS (Chip Select) instead of RST.
Am I correct in these assumptions: i.e., the first kind of pinout (RST/SCK/MISO/MOSI) does not support an external SPI sensor, and the latter (CS/SCK/MISO/MOSI) does?
Flip32 F3 flight controller; ISP pads upper-left:
MultiFlight Nano-B flight controller pin header schematic:
I don't know these boards, just had a look at some pics on the internet.
The Flip32 F3 seems to have an Atmel ATMEGA microcontroller on board. (as an auxiliary MCU) I would assume that the 6 pins you found are the ISP interace for that MCU.
Just use a multimeter in continuity test mode and check if the 6 pads are connected to the ISP pins of the ATMEGA.
The board's main MCU STM32 is more likely programmed through the SWD (serial wire debug) interface. That's a pin-reduced JTAG alternative. Just google for it.
Here are some details if you are interested in Atmels ISP:
http://www.atmel.com/images/doc0943.pdf
If the firmware supports it (or you write one that supports it) you should be able to use the ISP interface as a normal SPI interface which it basically is.
ISP is usually done through a simple serial interface like JTAG, SWD or in the AVR case SPI.
Best way to find out: Read the datasheet of your ATMEGA.

SH72867 with I2C

I am using ‘SH72867(Renesas)’ connect with ‘EEPROM(24LC04B)’ . In the customer’s document at ‘address 0xF0 of EEPROM have data 0x5555’, But when I reading from this address always return ‘0xFFFF’ and same with other address.
I can’t write to EEPROM too.
I used I2C sample of Renesas but not run.
Do you have any suggestion about setting up I2C?
Sorry for my bad English and no clear explanation.
Any help apprciated,
Thanks
Verify the common issues:
Data and clock are connected properly.
Pull up resistor on clock and data connected to VCC.
Loop the I2C read request, connect scope and verify that I2C signals are OK. In addition check the ACK bit.
Verify clock is lower then 400kHz.
When using code examples, they usually fit to specific board. Verify that the code example configuration is the same as your board.
Some MCU may have more then one I2C pinout options. The code example might use I2C module that connected to diffrent pins.

Power save mode STM32F205RG

I am using STM32F205RGT6 Cortex-M3 microcontroller and coding with IAR Embedded Workbench.
I plan to keep the microcontroller in a power saving mode most of the time except when an external component tries to either communicate via SPI (the STM32 microcontroller is meant to be a SP slave) or via USB.
One external compinent is connected via SPI (PB12-15) and PC is connected via USB (PA11-12).
The communication works fine - I have tested both the SPI as well as USB.
I figured that once I am done setting up SPI and USB I will call a power saving function and add the same function call at the end of interrupt service routines. I have found PWR_EnterSTANDBYMode and PWR_EnterSTOPMode (in stm32f2xx_pwr.h) both of which I tried using.
However with such arrangement I cannot establish any communication (SPI or USB) with the microcontroller.
Is there something extra that needs to be configured (for example which pins should wake the microcontroller up)?
Am I using wrong function? Or wrong header file?
Can you point me to an example resembling such case (I could not find anything similar on ST's website)?
Any constructive feedback would be welcome.
In the mean time I found the application note AN3430 (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00033348.pdf) which is somehow more digestible (only 38 pages) which gives an excellent overview on power saving in the microcontroller.
Since I don't have access to PA0-WKUP (the wake-up pin) I had to discard using stand-by. Seems that just a simple sleep mode in main loop - by calling __WMI(); - should lower current consumption enough in my case. I might consider stop mode if sleep mode isn't enough but I will have read fragments of datasheet on configuration of EXTI registers that the application notepoints to.