I have several devices on mdio bus - 1 phy AR8035 and 3 Dual Phys DP83849ifvs. The mdio bus is controlled by AM335x SoC. The problem is that I can't get mdio access to AR8035 PHY, but DP83849ifvs mdio r/w is ok. I check it with help of u-boot 2020.07 (mdio read 0 2 command). DP83849ifvs has 0,1,2,3,8,9 PHYIDs (they are dual phys so 2 addresses on one IC), AR8035 has 4 PHYID. When I try to read it with mdio read 4 2 I get Error. I wanted to look closely on MDIO frame via oscilloscope but I found strange behavior on MDIO bus - there are a lot of frames non stop, ~100us between them. I wonder is it normal behavior for MDIO bus assuming I am in u-boot environment? Maybe AR8035 was damaged, went crazy and now flooding the bus? Thanks!
Related
My problem:
I have connected a VEML6030 (Ambient Light Sensor from Vishay) to my µC.
If I want to read this sensor, I only get 0x0000 as an answer.
I'm programming in c on a Renesas r5F104GK.
I used Applilet as a code generator.
I have the data sheet and an application note as documentation. I have also already spent days searching online - unfortunately unsuccessful so far.
I also have a Lis3DH sensor on my PCB, which is connected to the same I²C bus.
I can separate both components from the bus with a jumper.
What I have already achieved:
Depending on the level of the ADDR pin, I see an ack on the bus.
identify veml6030
The communication with the Lis3DH works (read & write)
I get protocol-compliant Ack / NACK from the sensor.
The system is operated at 3V
If I try to read output, I only get 0x000:
Output
During the tests I am sure that only the VEML6030 is contacted.
I would be very happy if someone here could share their experience with the VEML6030 and, if necessary, have a tip on what I'm doing wrong.
In the end, I'm sure that the problem is in front of the monitor ;)
Update (#Lundin)
How can I move my ticket to electronics.stackexchange.com?
Unfortunately I can only publish a part of the schematic
2.1) SDA & SCL have got 10k Pullups
2.2) SDA is connected to µC Pin 18 (P14/RxD2/SI20/SDA20/TRDIOD0/(SCLA0))
2.3) SCL is connected to µC Pin 17 (P15/PCLBUZ1/SCK20/SCL20/TRDIOB0/(SDAA0))
2.4) INT is connected to µC Pin 36 (P140/PCLBUZ0/INTP6)
The Connector at ADDR is just used to get the correct footprint on the PCB. In real it is a Jumper with 3 pins.
P.S.: Solved Communication
enter image description here
I hope this is the correct way now.
My problem is solved.
I've to send only a "Start".
we are currently evaluating to use an external SRAM for C/C++ heap storage on our platform using a STM32F439BI microcontroller.
The problem
Using the SRAM as storage for heap results in random hardfaults which are raised from buserrors/imprecice buserrors.
Without placing the heap on the SRAM, memory tests run successfully on the whole SRAM (8 bit/16 bit and 32 bit accesses).
Connecting a debugger I can observe these errors sometimes before a hardfault occurs. Most often a word is read from the SRAM and the CPU register fills with addresses of the following format: 0x-1F3-1F3 (- is most often '0', sometimes 'A' or '6'). The pattern '1F3' persists. If the same address is read again some lines further down the correct value is read (some other address in 0x60000000 space).
If I stop the program on a breakpoint at some point early in the program and step a few lines, I get these errors more frequently.
Further details
The SRAM is connected using the FMC/FSMC peripheral on FMC bank 1 and SRAM bank 1 and is therefore memory-mapped to address 0x60000000.
All settings for GPIO pins and FMC configuration are set from the startup file before main() executes or static objects are created.
The SRAM is the following: CY7C1041GN30
We connect all 16 data pins, all 18 address pins, BHE, BLE, OE, WE and CE to our controller. All pins are configured as push-pull-alternate-function, pull-up, AF_12 (FMC), very high speed. We enable clocks for all necessary pins and the clock for FMC. Note: Initially we started out without pull-up/down showing the same symptoms.
The controller runs with a clock speed of 168 MHz
As stated above, a memory test runs successfully
We use DMA for SPI, I2C and ADC data transfers
We frequently use interrupts, including external (pin) interrupts
We use the following timing settings:
AddressSetupTime: 2
AddressHoldTime: 4
DataSetupTime: 4
BusTurnAroundDuration: 1
CLKDivision: 2
DataLatency: 2
We configure the FMC as follows:
NSBank FMC_NORSRAM_BANK1,
DataAddressMux FMC_DATA_ADDRESS_MUX_DISABLE,
MemoryType FMC_MEMORY_TYPE_SRAM,
MemoryDataWidth FMC_NORSRAM_MEM_BUS_WIDTH_16,
BurstAccessMode FMC_BURST_ACCESS_MODE_DISABLE,
WaitSignalPolarity FMC_WAIT_SIGNAL_POLARITY_LOW,
WrapMode FMC_WRAP_MODE_DISABLE,
WaitSignalActive FMC_WAIT_TIMING_BEFORE_WS,
WriteOperation FMC_WRITE_OPERATION_ENABLE,
WaitSignal FMC_WAIT_SIGNAL_DISABLE,
ExtendedMode FMC_EXTENDED_MODE_DISABLE,
AsynchronousWait FMC_ASYNCHRONOUS_WAIT_DISABLE,
WriteBurst FMC_WRITE_BURST_DISABLE,
ContinuousClock FMC_CONTINUOUS_CLOCK_SYNC_ASYNC,
WriteFifo 0,
PageSize 0
We spend a lot of time of experimenting with longer timings and compared all the settings to examples including this one: Using STM32L476/486 FSMC peripheral
to drive external memories (although this one is for the STM32L4, I am fairly certain it applies to this controller as well)
Findings on similar problems
The problem sounds very similar to this errata sheet entry: "2.3.4 Corruption of data read from the FMC" but it also says the error is fixed in our revision of the controller (3)
I hope someone out there has seen this strange behaviour before and can help us. After over one week of debugging we expect some kind of error in the controller when interrupts/DMA accesses occur while the CPU accesses the SRAM (when we use it as heap, it is accessed very frequently). Hopefully you can shed some light on this topic.
Sorry for not getting back to you, internet.
Yes, we found out what the issue was (at least in our case). Problem was that the J-Link debugger we use is causing problems if it hangs above the power electronics on our pcb (it is mounted vertically). If we guide the ribbon cable out at the top (only digital electronics) the error disappears. So our guess is, that some noise from the electronics was caught up by the cable and directly injected into the JTAG port, which caused failures inside the MCU.
Just got a confirmation from ST, that there is a bug in the STM32F469 FMC that might cause incorrect values if the write fifo is disabled. The workaround is to have the fifo enabled. It is the same issue as in this F7 processor https://www.st.com/resource/en/errata_sheet/dm00145382.pdf
I'm attempting to interface an STM32F303 Nucleo with an AD7748-4 ADC. Datasheet for the ADC:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7768-7768-4.pdf
The issue is, the ADC DOES NOT output the converted value through the SPI port, but rather employs a Data Ready Signal (DRDY), a Data Clock (DCLK), and a combination of 4 Data Outputs (DOUT0-DOUT3). The output streams 96 bits serially through one wire if I set it up that way, but timing is critical in my application and I need to clock the data in using DOUT0 to DOUT2, which would each output 32 bits. If I were serially streaming the data, I could trick the SPI port into reading it, but I'm not. The ADC is running at 20MHz, so DCLK will be operating at the same frequency. The Nucleo runs at a maximum of 72MHz, but when the DAM is utilized, it sets the clock to 64MHz.
In the STM manual, it describes a "GPIO port input data register (GPIOx_IDR) (x = A..H)" as being a read only register - my understanding is that the lower 16 bits can store an inputted value up to 16 bits (most likely for memory data R/W) - so the question is, how can I configure the GPIO to read in the data? I'm at a slight impass here. My instinct tells me that the Nucleo may not be fast enough to read the data coming from the ADC... Any ideas? All being written in C/C++ basically bare metal... I'm new to the Nucleo, haven't written code in 4 years - pardon any lapse in knowledge...
If DCLK works at 20Mhz, the uC is obviously not fast enough (you have about 3 instructions between each cycle, so even assembly language would be difficult to implement...). As I am not familiar with the stm architecture, I can only suggest a trick that will maybe spark some ideas in your head. Rather than using a crystal for the ADC, use a timer from the STM that is connected to an output pin, and clock the ADC using that pin (MCLK). When configuring the ADC using spi, idle mode, etc. you can leave this clock signal at 20Mhz. But when you need a sample from the ADC, stop the STM timer and clock the ADC "manually". (you practically control the DCLK signal). After your conversion routine is over, restart the timer at 20Mhz.
I have wired up my ESP32 and after I power it, it keeps on restarting with the message:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0xffffffff,len:-1
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0xffffffff,len:-1
ets Jun 8 2016 00:22:57
I have connected a number of devices with a keypad connected on GPIOs [6, 7, 8, 15, 4, 16, 17, 15] and both RTC and LCD Serial Adapter connected on pins [21, 22]. All devices are powered by the ESP32's 5V pin.
Now, strangely, when resetting, if I press number 1 on the keypad (4x4) or disconnect it, the resetting stops and everything works as expected even after reconnecting it. The same happens with the LCD serial adapter. All other devices do not affect the ESP32.
Any insight as to what may be causing this peculiar behavior will be greatly appreciated.
From the ESP32 you can safely pull about 12mA amount of current. You probably have too many devices powered by it's 5V pin.
Consider using an additional power source. Don't forget to interconnect the GND if do it.
Your logs seem very similar to what I was getting for over a month. Flashing a non-secure-boot enabled project was ok. But building and flashing the exact same project with secure-boot enabled (under menuconfig) gave me the 'bootloop' with
"load:0xffffffff,len:-1"
It could be that your bootloader.bin size exceeds the default limit (0x7000). This would cause an overlap in the default offset (0x8000) for partition table.
For my case, my bootloader.bin size was about 0x9000 (did a hexdump).
To overcome this, I changed the partition table offset from 0x8000 to 0x10000 under menuconfig. (This resulted in the offset of the app image to shift from 0x10000 to 0x20000) Then flash accordingly with 'esptool.py write_flash...', or use 'idf.py flash'.
Another way is to reduce the size of the bootloader.bin, perhaps by reducing the verbose output to 'warning' or 'error'
First thing to always try is the process of elimination. Remove one device at a time to see which one attached is causing the problem.
But looking at the data I have is GPIO 6-11 is used by the flash memory. Might double-check me on that. I have a doc from Andreas Spiess that has the pinouts of several boards and has those GPIO blocked out as unusable as they are used by the flash memory.
Ist there any possibility to read values from the pins of the COM Port? Any solution in C under Linux is appreciated!
Yes, see for instance this guide.
You use the ioctl() function, to read the various control pins. Data is, of course, best read through the normal read() handling, you don't want to be polling asynchronuous serial data.
I don't think your assumption (expressed in a comment) that the driver must check the pin-states to handle data is correct, normally a serial port is "backed" by an UART and that typically handles the RX/TX pins in hardware.
Am pretty sure , you can't read/write pins of UART.
Even at the hardware level , you have to read/write an entire byte.There is no bit access or read/write pin access.
The Byte is read/written in the Receive/Transmit UART buffer .
In either ways you can't just access the buffer directly , on your behalf the linux driver will do the job. You just have to make use of the driver in your application , to work with the UART , the linux driver for UART provides , standard API's like open(),read(),write(),ioctl() through which you interact the UART device.
If you want to work with drivers , and new to this field , the best place to start will be
this book.
The exact answer to this question depends on the precise hardware in question. I know of a piece of code where I worked, based on receiving the letter 'a' as the indication of bitrate, and it would poll the RX pin to detect the transitions between 0 and 1 to detect the "width" of the bits, and it would then calculate the correct clock-rate for the serial port and configure the serial port to match the bitrate of the other end.
A "PC" type hardware solution will not be able to read the RX/TX pins. In other hardware, it may be possible to do so. Many embedded systems allow various pins to be configured as inputs, outputs or "have a function" (in our case, RX, TX, CTS, RTS, etc) - so for example, you could configure the RX pin to be a input, and thus read the state of it. Of course, the normal serial port drivers will probably set these pins to "have a function" [or expect the boot code running before the kernel is started to have configure it this way]. So you would have to reconfigure the pins in some kernel code of your own, most likely. Beware that this may cause unexpected side-effects with the driver for the actual serial port - it may "get upset" when it tries to do things to the serial port and it's "not working as expected" because it's been "misconfigured".
You can almost certainly read (and/or write) the state of the control pins, such as CTS, RTS via IOCTL calls.