Enabling DDR in SD/MMC causes problems? CMD 11 gives a response but the voltage switch wont complete - linux

I am trying to enable DDR in sd (spec above 2.0) the procedure in the specifications is as follows
Execute CMD0 to make the card idle
Execute CMD8 to enable ask about the voltage requirements
Execute ACMD41 with S18 bit enabled and log for S18 in the reply to see if the card has voltage switch functionality: checked and the card has the functionality
Now execute CMD11, if the card replies with a response the voltage switching sequence is started, the cmd and data line should go low: checked and yes they do
Stop the clock,
Program the voltage switch reg (with 1.8V) and wait 5 ms
Start the clock: the card should start at speed SDR12 with 1.8V: cmd and data lines should go high, a cmd_done interrupt should be received: NOT RECEIVED
Any pointers regarding this would be helpful...the card status registers shows that there is a data transfer in progress and the card is not present. After this I cannot execute any CMD (the cmd_done interrupts are not received)

For the sake of helping others, the process explained above is correct. The problem was on the board side i.e. there were no 1.8v regulators connected on the board. So first make sure that the SOC or the board has those connectors available. In case of mmc, ddr mode can be enabled with 3V so the above case is only valid for sd.....

Related

Gigabit Ethernet takes ~370ms to report link down in MII register

To give you some context, I am trying to configure some network redundancy on Ubuntu 20.04.
I decided to use NIC bonding with:
2 Gigabit interfaces,
active-backup mode,
link state monitoring with MII (polling every 10ms).
It works as expected, when the active slave fails (wire unplugged) the bonding switches to the other slave. However this transition is too slow in my opinion as it takes up to 400ms.
In order to investigate I had a look at the MII register using this command: mii-tool -vv ens33 (-vv is to print raw MII registers content). It generates this kind of output:
Doing a basic bash script I print current time + value of the 2nd MII register which contains the link state. As this is a "while true" loop with no pause, I get a status every 20ms, so it allows me monitoring with enough reactivity.
Observed behavior:
when the interfaces are configured with a 100Mbit/s speed, Full Duplex => the MII register is almost immediately updated (no "visible" delay between the wire unplugging and the update of the register value on the screen).
however when configured at 1Gbit/s, Full Duplex (via auto-negotiation) => the update of MII register takes much more time (it is "visible" with the bash script). By sending pings every 10ms using the bond interface, and logging packets with Wireshark on receiver side, the observed delay is around 370ms.
My questions:
The Ethernet controler is an Intel I210, and I have not found anything relevant in the datasheet.
Do you see any reason for such a long time to detect link down when interface speed is 1Gbit/s vs 100Mbit/s (370 vs 50ms) ?
Any advice to improve the reactivity?
Thanks for your help :)
Every generation of Ethernet speed has it's own method and requirements.
10BaseT:
"link pulses" are used every 16 ±8 ms
100BaseT: "link pulses" are not used but Idle ("/I/") 4B/5B code words monitoring is instead.
1000BaseT: link failure is actually
determined by maxwait_timer which is defined in IEEE 802.3 to be 750 ±10 ms for Master and 350 ±10
ms for Slave ports.
As you can see, your measured 370ms are exactly what you can expect from a slave port.
Sources:
https://www.microchip.com/forums/FindPost/417307
https://ww1.microchip.com/downloads/en/Appnotes/VPPD-03240.pdf

How to monitor XBee GPIO data through X-CTU console?

I'm using PIR sensor for motion detection and XBee s2c for transmission. The remote(transmitting) XBee, connected to PIR, is configured as below
CE=0
DH=0
DL=0
D4=3
IR=3E8 (500ms)
IC=FF (Change Detection on all pins)
The base(receiving) XBee is configured as below
CE=1
DH=0
DL=FFFF
D4=5
At the base, GPIO4 is connected to an LED. I have performed a simple test as mentioned here to check whether the GPIO is working or not. It's working as mentioned with above given DH & DLs. As D4 is configured to 5, the LED glows all time. Theoretically, whenever PIR sends high, LED should be off and vice-versa. But I am having two problems
The console of remote XBee is not showing any frames being sent but console of base XBee is showing the receiving frames and it is receiving correct data of PIR.
The pin D4 of base is not following the data being received i.e, it stays high all time.
I have observed the frames being received and they are showing the response of PIR as intended. How is the pin D4 not following the frames being received? I have followed this tutorial for DIO lines passing of XBee.
Make sure you're running the 802.15.4 (ATVR=0x20XX) or DigiMesh firmware (0x90XX) and not the ZigBee firmware (0x40XX). Looking at the options in XCTU, I don't think ZigBee firmware supports I/O line passing.
And looking at that knowledge base article, you might need to set ATIT on the remote and ATT4 and ATIA on the base. If those registers aren't available, then you're probably running a firmware version that doesn't support I/O line passing.

Cubieboard2 - how do I set GPIO high during boot and keep it high?

I am trying to adapt a circuit for soft-power from Raspberry to Cubieboard (http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch). It appears to be working just fine but it needs a pin from the board to be set high while it is running (actually the description is for input with pull-up, but that's not the problem).
I have managed to set the PH15 pin as output high in uBoot script via gpio set 263. However about 3 seconds into the boot process something sets it low back again. The fex file is set correctly to adjust it to output high (tried input with pull-up too) but that appears to kick in several seconds later (about 7-8 seconds in the boot). As a result during the boot process the soft-power circuit just dies reacting to the low state of the pin.
So that is the puzzling question - how to set a pin on the Cubieboard immediately during boot and keep it that way? What brings it down?
Using kernel 3.4.79 with some config options (rtc, drivers, etc - nothing exotic).
Any help appreciated. Modifications to the circuit acceptable too!

Tell when Bluetooth module connects on Arduino

I'm working on a project with Android and Arduino and am trying to figure out how on the Arduino side to tell if the Bluetooth is connected or not.
I'm using one of these Bluetooth Modules to connect. I know I can send a command through Android, but I'm trying to have an action happen automatically when they connect and not have to run a background application on the Android if possible.
Using the module supplied and nothing else you cannot: notice the module has four connectors:
Power (Vcc)
Ground
Tx (send)
Rx (receive)
Given this interface the only way to determine whether the bluetooth module is paired is to send something to the paired device and have it respond in such as way that your Arduino knows that it is connected. For instance, if your Android program always responds with "Hi there!" when it receives a string "Hello?", then by seingin "Hello?" your Arduino will know that it is paired with your Android phone/tablet. Your Arduino could poll (send the interrogation string) every minute (or every five seconds) to see if it is paired with your device.
There is a better way, but it will require some soldering on your part. If your module is HC-03/HC-05-based, then the PIO9 pin is the "paired indicator LED" (see datasheet here). You could connect that pin to an Arduino input pin and read the level: reading digital 1 will indicate that the device is paired, while reading digital 0 will indicate that it is not. It is possible, though not certain, that the pin on your module labeled STATE is exactly this kind of a pin, i.e. it indicates the paired status. Unfortunately. this pin it isn't connected to the header, so you'll have to solder a wire to the correctponding pad to connect it to your Arduino. You should test it first by connecting a multimeter in voltage mode to that pad and measure the potential between that pad and ground in paired and non-paired state. If this is the pin that responds to the paired state then you are golden. It might be that it indicates power (like the HC-03/05 PIO8 whilc blinks when on). If it turns out that the STATE pin is not the pairing status, then you should request a datasheet from your supplier, and use that to find the status LED connection: one is likely to exist. Once you found the correct pad, verify its function using the voltmeter again. Then solder a wire to that connection and read it from your Arduino.
IMPORTANT: Make sure that your Arduino never puts out a digital 1 on the Arduino pin connected to the bluetooth module status pin: these bluetooth modules run on 3.3V, and connecting any unprotected pins to 5V will be damaging. The Vcc and Txd pins are voltage shifted in the module you bought, but the LED/Status lines are likely not to be. So if the Arduino pin connected to "status" on your Bluetooth module is configured as output and you digitalWrite(HIGH) to it, you will likely damage the Bluetooth module.
Unfortuntaely, the HC-05 will switch states when paired, but won't output a 1 until it's actually connected to something.
For instance, I can unpair my phone from the HC-05, pair again, and then the LED will change state, but the output of the STATE pin is still 0. If I open up an app, and connect to the device manually then the LED, and STATE pin will change state. The LED will periodically blink twice, and the STATE pin outputs a 1 to the Arduino.
If you would like to read the the value of the STATE pin, connect a wire to any of the inputs to the arduino, and code Serial.println(digitalRead(inputPin)); inputPin being the wire to the input of the Arduino.
I've been fighting this thing for months, and have yet to find a way to make this thing automatically connect to my phone. It won't even allow for me to connect to it from my phone to the HC-05 unless I download an app onto my Android. It's possible to bind the HC-05 to a certain address, but even this did not work for me. I want to mess with the "AT+CLASS" command, but the documentation behind the instruction has hindered me thus far.
From the HC-05 datasheet we see that the connection status depends on the output from PI09. Apparently sending "AT+BIND?" to the module will return the status of PI08 & PI09 in the form,
"+ POLAR=PI08,PI09" however this makes no sense to me because in order to get this you must enter AT mode and entering AT mode will disrupt the paired connection, hence it will always send PI09 marked as "not connected".
THUS in order to see if the connection is still live from the arduinos POV I can only see 2 feasible ways:
Program arduino to, every so often, send a "hello?" and if it doesn't receive the expected "Hi back" response, then it is to assume that it isn't connected.
Connect PI09 to an arduino input pin and read it's value whenever you want to check if the connection is live or not
AT+STATE? will return the current state of the connection. Yes you will need to enter at mode, that is done by bringing up pin 11 HIGH on the HC05 module. It does require soldering but it's kinda worth it. It then allows full AT control of the device, then set it LOW to return it to normal working mode.
Another option, which I don't fully understand, is the AT+MPIO? command, which returns the state of all the pins in some strange masked format I don't understand yet.
I use the first option above so that I can terminal (Bluetooth) from my phone to the HC05 and switch on a led/relay etc (ie bring up pin 2 to HIGH) on the HC05. This required entering AT mode (pin 11 HIGH), sending the command AT+PIO=2,1 and then setting pin 11 to LOW to return to normal working mode.
Note: I noticed I had to put a 200ms delay in between high and AT and LOW commands. Angela's solution is nice - I use a cheap XBEE Bluetooth module (HC-05 Bluetooth Bee Master & Slave Module with Bluetooth XBee for Arduino uk2015) 2 units(HC05/6) for 5Stg which are laid out in XBEE format - handy for the 3.3v.

SPI data transfer - why MOSI goes to zero half cycle before the data transfer?

I have an SPI signal output from a SPI device. I wonder why the data output (MOSI) goes to 0 half cycle before the actual data is written on the bus? Is it a must condition for an SPI device? If it does not go to zero, would there be any problem on the data transfer?
I use spidev32766.1 on linux (ubuntu 12.04 - kernel 3.7.1), the processor is imx233
Thank you in advance!!
The slave device doesn't care what happens on the data line except for a very short period (usually <1ns) either side of its active clock edge (this window is defined by the setup and hold time specifications for the interface).
I have no idea why your system would put out that "wiggle" though!

Resources