I have an existing embedded system with an existing developed C code.
Sometimes the microSD card can lock down giving responses outside of the scope of the existing system.
I'm currently unsure why but suspect the handler in the existing system allows subsequent calls to be made too quickly.
The card is being used in Spi mode to have direct I/O.
The circuit diagram does not show any control over the power to and from the card so I cannot just reset and re-connect to the fresh Spi.
My only option seems to be finding a way to get it to reset through an Spi call, or look at creating a function to recover the sd back to its' expected state from whatever lock it is in.
With that in mind, is there a command or set of commands I can use to cause the equivalent of a reset, or to cancel whatever the microSD controller is expecting?
Looking at the SD associations' specs, the only reset reference is the CMD0 and that isn't applicable once into Spi mode.
Any thoughts are welcome, and thank you in advance.
-Chris
Related
I have built a simple PCI driver for reading and writing data to a PCI device. I have also added interrupt support, so when there is a PCI interrupt an ISR is called. This all seems to work.
I would like to inform an external application of the interrupt. So far I haven't found a suitable mechanism. The interrupt could come at any time, and is dependent on Sensors connected to the PCI device.
I have found the following:-
1 Event objects which can be passed to the KMDF driver via read, write, iocontrol commands (Overlapped object)
2 Plug and Play notifications, which can be use used by (Toaster example code) the driver to inform the app of PNP events.
A notification method would be ideal, however it doesn't look like one exists for my particular use case.
There are at least 2 ways to achieve what you are looking for
Inverted call model - send IOCTL(s) to the driver which the driver will keep pending and will complete them as and when it needs to notify the user mode about the occurrence of the event that it is interested in. You can read more about this approach here.
Use shared event handles. A user mode application communicates the event handle(s) to kernel mode using an IOCTL. The kernel mode increments the reference count to ensure that the handle remains valid when it needs to use it and then signals the event when necessary. You can read more about this approach here.
The first approach is more preferred for various reasons that you will find while reading the linked articles. If your use case requires the kernel mode to not only indicate the occurrence of an event but also send some data back to user mode then the second approach is not suitable for your requirement and you should focus on the first approach alone.
I am building a small embedded device. I am using a reset switch, and when this is pressed for more than 5 seconds, the whole device should reset and clear all the data and go to factory reset state.
I know what to clear when this event happens. What I want to know is how do I raise this event? I mean when switch is pressed, how do I design the system to know that 5 seconds have elapsed and I have to reset now. I need high level design with any timers and interrupts. Can some one please help me?
Depends on the device. But few rough ideas:
Possibly the device manual may say about the number of interrupts per second that is produced by "holding down the switch" (switch down). If you have this value, you can easily calculate the 5 seconds.
If not, you would need to use timer too. Start the timer when you get the first interrupt of "switch down" and count up to 5 seconds.
Note that, You should also monitor for "switch up", that is, "release of switch". I hope there will be an interrupt for that too. (Possibly with different status value).
So you should break the above loop (you shouldn't do the reset) when you see this interrupt.
Hope this helps.
Interrupt-driven means low level, close to the hardware. An interrupt-driven solution, with for example a bare metal microcontroller, would look like this:
Like when reading any other switch, sample the switch n number of times and filter out the signal bounce (and potential EMI).
Start a hardware timer. Usually the on-chip timers are far too fast to count a whole 5 seconds, even when you set it to run as slow as possible. So you need to set the timer with a pre-scale value, picked so that one whole timer cycle equals a known time unit (like for example 10 milliseconds).
Upon timer overflow, trigger an interrupt. Inside the interrupt, check that the switch is still pressed, then increase a counter. When the counter reaches a given value, execute the reset code. For example, if you get a timer overflow every 10 milliseconds, your counter should count up to 5000ms/10ms = 500.
If the switch is released before the time is elapsed, reset the counter and stop the timer interrupt.
How to reset the system is highly system-specific. You should put the system in a safe system, then overwrite your current settings by overwriting the NVM where settings is stored with some default factory settings stored elsewhere in NVM. Once that is done, you should force the processor to reset itself and reboot with the new settings in place.
This means that you must have a system with electronically-erasable NVM. Depending on the size of the data, this NVM could either be data flash on-chip in a microcontroller, or some external memory circuit.
Detecting a 5S or 30S timeout can be done using a GPIO on an interrupt.
If using an rtos,
. Interrupt would wake a thread from sleep and disables itself,
. All the thread does is count the time the switch is pressed for (you scan the switch at regular intervals)
. If the switch is pressed for desired time set a global variable/setting in eeprom which will trigger the factory reset function
. Else enable the interrupt again and put the thread to sleep
. Also, use a de-bounce circuit to avoid issues.
Also define what do you mean by factory reset?
There are two kinds in general, both cases I will help using eeprom
Revert all configurations (Low cost, easier)
In this case, you partition the eeprom, have a working configuration and factory configuration. You copy over the factory configurations to the working partition and perform a software reset
Restore complete firmware (Costly, needs more testing)
This is more tricky, but can be done with help of bootloaders that allow for flashing from eeprom/or sd card.
In this case the binary firmware blob will also be stored with the factory configuration, in the safe partition and will be used to flash controller flash and configurations.
All depends on the size/memory and cost. can be designed in many more ways, i am just laying out simplest examples.
I created some products with a combined switch to. I did so by using a capacitator to initiate a reset pulse on the reset pin of the device (current and levels limit by some resistors and/or diodes). At start-up I monitor the state of the input pin connected to the switch. I simply wait until this pin goes height with a time-out of 5 seconds. In case of a time-out I reset my configuration to default.
The STM32 family of microcontrollers features a read-out protection feature so proprietary code can't be read out via the debug interface (JTAG or SWD).
Using OpenOCD, how can I enable/disable the read-out protection via a SWD/JTAG interface? How secure is the RDP read-out protection?
If possible, please give an answer valid for the entire STM32 family.
RDP levels
First, you have to know which level of readout protection you want to set (refer e.g. to section 3.7.3 of the STM32F4 reference manual):
RDP level 1: This level is reversible. Once you disable it, the system memory is mass-erased and you can re-program
RDP level 2: This level is irreversible and disables the debug interface altogether. The only way of updating your firmware is via some bootloader mechanism.
Usually you want to activate RDP level 1. In order to avoid mistakes that will certainly brick the microcontroller, I will not show how to enable RDP level 2 in this answer. Refer to the reference manual for details.
Activating it using OpenOCD
The activation feature is actually built-in into OpenOCD using the lock command. Just like executing the program command to flash your firmware, you can use the stm32f1x lock command (or stm32f2x lock for STM32F2/F4) to activate it.
A typical OpenOCD configuration file would look like this (you need to flash the correct firmware before running this):
# Set RDP to level 1
init
reset halt
stm32f1x lock 0
reset halt
exit
Note that the readout-protection will only be in effect once the microcontroller is reset or powered off (that's why there's a second reset in the command sequence).
A typical OpenOCD call could look like this:
openocd -d0 -f stlink-v2.cfg -f ocd-stm32f0.cfg -f ocd-lock.cfg
where ocd-lock.cfg contains the command sequence shown above.
Once activated, you can verify that the RDP is active by trying to flash the MCU using your usual programming command sequence
Deactivating RDP
Deactivating it is just as simple: Just use stm32f1x unlock (or stm32f2x unlock for F2/F4 devices) like this:
# Set RDP to level 0
init
reset halt
stm32f1x unlock 0
reset halt
exit
How secure is it?
That's a tough question that can't really be answered without additional information. One summary answer I can give is that it's pretty secure if you assume the protection has no inherent bugs and someone uses software tools only.
One of the most popular methods of resetting the RDP bit without mass-erasing the flash is to disable the RDP with a laser. Given the fact that the STM32 family is not a family of dedicated security microcontrollers with specific countermeasures, this is rather easy if you have the right equipment and sufficient experience in this area. Even some specific security MCUs have some security issues, see e.g. the Security from the IC backside talk. However, most low-level attackers will usually refrain from the cost of doing so.
Another solution is using Segger Jlink 6.60c (or later if available)
with J-Link unlock STM32 software.
Just run it, it will notify about following: "If read protection of the device is enabled, reset the option bytes will cause a mass erase". Click OK. It will ask for device family. Enter device family (my choice was 12 for STM32L4R9ZI) and press Enter.
If all good the output will be like this:
Please select the correct device family: 12
Connecting to J-Link via USB...O.K.
Using SWD as target interface.
Target interface speed: 1000 kHz.
VTarget = 3.396V
Reset target...O.K.
Reset option bytes to factory settings...
Resetting FLASH_OPTR...
Reset target...O.K.
Reset target...O.K.
Resetting Write protection (WRP) and PCROP...O.K.
Reset target...O.K.
Option bytes reset to factory settings.
Press any key to exit.
I have a Netduino Plus with at transeiver attached via SPI. I would like to reset the transiever every time the Netduino restarts. Is it possible to programmatically power on/off the 3V3 pin?
I would recommend using a FET (controlled by one of the I/O) pins to enable/disable 3V3 power to your transceiver. When you say transceiver, I think "more than a few mA" :)
BTW, we took this feedback into account with the new Shield Base module for Netduino Go. It has an integrated FET on both 3V3 and 5V power headers, so you could enable/disable power to your shield in code. Once the new Ethernet go!bus module ships and the Shield Base comes out of beta (soon), your solution can be redeployed to Netduino Go + Shield Base with few/no code changes.
Chris
Secret Labs LLC
Looking at the circuit diagram ( http://www.netduino.com/netduinoplus/schematic.pdf ), I can see only the Micro SD Card Slot having its power controlled programmatically. You could rig up a relay to control it (via a transistor, of course) instead, or if the transceiver uses less than 130mA (the current limit of the device shown: http://www.datasheetarchive.com/BSS84W-7-F-datasheet.html) you could copy the circuit from the Netduino Plus. Buying a relay shield looks like overkill, but you might have other uses for it.
Have you looked into resetting the transceiver programmatically instead of the brute-force method of power-cycling it?
Just to provide another view. You could use a transistor powered off the netduino RESET line, this will reset the device every time the netduino reboots. Or you can just link the transistor to a spare digital pin and power it in code..
What specific SPI device are you using? You mention that it's a transceiver but we could probably provide better information if we know the exact part number. If your device requires less than 8mA the Netduino Plus specs seem to indicate that one option could be using a digital output pin as the power source.
Unfortunately Secret Labs don't use exactly the language I'd expect and call out the sink and source current maximums so I would contact them directly first to see if you risk blowing your chip. I'll see if I can get an answer from them and amend this post if/when I do.
Update: Sink and source current is the same on the Netduino. See my post on their forums about sink vs. source current for a more in depth explanation. So, if your device can run off of just a few milliamps you should be able to use a digital I/O pin to power it.
Also, a lot of devices have enable pins. You can usually reset them with that line instead of pulling the power if that helps. Sometimes with flaky hardware it is better to pull the power though.
it seems that as soon as data is ready for the host (such as when I use WriteFile to send a command to the HID in which I tell the HID to give back some data such as the port value) and the in packet ready bit is set, the host reads it (as confirmed by another USB interrupt) before ReadFile ever is called. ReadFile is later used to put this data into a buffer on the host. Is this the way it should happen? I would have expected the ReadFile call to cause the in interrupt.
So here is my problem: I have a GUI and HID that work well together. The HID can do I2C to another IC, and the GUI can tell the HID to do I2C just fine. Upon startup, the GUI reads data from the HID and gets a correct value (say, 0x49). Opening a second GUI to the same HID does the same initial data read from the HID and gets the correct value (say, 0x49; it should be the same as the first GUI's read). Now, if I go to the first GUI, and do an I2C read, the readback value is 0x49, which was the value that the 2nd GUI had requested from the HID. It seems that the HID puts this value on the in endpoint for all devices attached to it. Thus the 1st GUI incorrectly thinks that this is the correct value.
Per Jan Axelson's HID FAQ, "every open handle to the HID has its own report queue. Every report a device sends goes into all of the queues so multiple applications can read the same report." I believe this is my problem. How do I purge this and clear the endpoint before the 1st GUI does its request so that the correct value (which the HID does send per the debugger) gets through? I tried HidD_FlushQueue, but it keeps returning False (not working; keep getting "handle is invalid" errors, although the handle is valid per WriteFile/ReadFile success with the same handles). Any ideas?
Thanks!
You might not like this suggestion, but one option would be to only allow one GUI at a time to have an open handle. Use your favorite resource allocation lock mechanism and make the GUIs ask for the HID resource before opening the handle and using it.