I have a Buffalo SDHC SD card with 4GB of storage, and a Raspberry Pi Pico. I have connected the SD card to the Pico's relevant SPI pins and have set the SPI clock speed to 1MHz.
I have reset the SD card with command 0, and have received a successful R1 response of 1 (to clarify, that is all I have done).
Now, I want to read a single block (512 bytes), and after researching, the command code is 17 and the arguments is the block index I want to read (in my case, 0 - 0-511 bytes). I have sent the command, and have received an R1 response of 1 (meaning card is in idle mode), however after some research, I was supposed to also receive a "token" containing 0xFE indicating a successful read followed by the bytes in the sector, or an error code.
However, the only things I am receiving after the initial R1 response are 0xFF bytes which would indicate the SD card is idle. I have tried reading several thousand bytes from the SD card, perhaps thinking the read is taking a while, but nothing, I am only receiving 0xFF bytes with the token nowhere to be found.
Does anyone have any advice on why this could be the case? I have looked over my command syntax and have found it to be correct:
(bits + cmd code) 01010001 (32-bit arguments) 00000000 00000000 00000000 00000000 (CRC value set to 0 due to checking disabled + end bit) 00000001
I have also tried experimenting with a different argument and different clock speeds but to no avail.
Related
I have bought the wavesharebarcodereader module (https://www.waveshare.com/wiki/Barcode_Scanner_Module) and managed that it decodes codes and sends the data to the rpi. Now i try to use it in command Mode where i can trigger the scanning by sending a byte array.
In my understanding this is an Array of Hexadecimal bytes so i need to suffix each byte with a 0x so i wrote echo "0x7E 0x00 0x08 0x01 0x00 0x02 0x01 0xAB 0xCD" > /dev/serial0 and the voltage of the tx pin drops for a moment as if it would send but the device doesnt react or answer. I also tried without the quotes or single quotes or without the 0x suffix but the device doesnt "understand" it and doesnt react.
Im sure the cabeling is correct and i tested the pins by connecting rx to tx straight and that works too. The barcodereader does work on 3.3V pins too so that is not the problem. I also tried sending the bytes with an arduino but the reader doesnt respond to that either. Sadly all the Documentation on the Reader is this: https://www.waveshare.com/w/upload/d/dd/Barcode_Scanner_Module_Setting_Manual_EN.pdf
Ive been stuck on this problem super long because im very new to uart bytes so any help would be appreciated.
Alright i figured it out:
i needed to use the command: printf "%b" '\x7E\x00\x08\x01\x00\x02\x01\xAB\xCD' > /dev/serial0 and that worked
I'm trying to disassemble a BIOS image for the 68000, and I'm having trouble getting IDA Pro 6.5 to correctly cross-reference addresses.
For those who aren't aware, the Motorola 68000 has a couple of interesting features/quirks related to addressing:
When given a 16-bit absolute address, the processor sign-extends it to 32 bits before dereferencing it.
The 68K uses a 24-bit address bus, so the high byte in a 32-bit address is ignored.
The original authors of this BIOS took advantage of these properties in a number of places to save a few bytes: for any address above 0xFF8000, it's possible to specify the address using only two bytes instead of four. For example, if I wanted to access the memory at address 0xFF9134:
lea (0x9134).w, a0
< sign extension >
lea (0xFFFF9134).l, a0
< discard high byte >
lea 0xFF9134, a0
The problem I'm running into is that IDA Pro is performing the sign extension, but then considers the entire 32-bit address instead of only the lower 24 bits. IDA ends up trying to cross-reference addresses that don't (or at least shouldn't) exist, and any segments/code/data I have in the 0xFF8000-0xFFFFFF address range get completely ignored.
I'm still new to IDA Pro, so I don't know if this would be solvable with a script, let alone how to write such a thing. Is there a way I can get the disassembler to correctly handle this dirty/clever addressing trick?
I have the same problem. My decision was to create custom_ana callback and then change every operand address as the following: op.add &= 0xFFFFFF.
But it is not so easy. Because you don't have fully recognized "cmd" at this moment, and you must prepare it by your own code.
I am generating and playing sound over MIDI messages. I need to do some stereo effect (change balance) but I can't find solution.
Now I am trying to use "Chan 1 Control/Mode Change" messages with parameters "08" (first byte) and "0..127" (second byte) but this doesn't work. Can you help me? Thanks.
Your first byte must actually be indicating that you want to send a control change message, and on what channe. Use 0xB0 to send CC on channel 1 before sending the CC number and then value.
Not all devices are going to respond to all CC messages. If you're sending 0x08 and 0x00 - 0x7F and nothing is happening, you probably have such a device.
You might also be trying to change panning instead, which would be 0x0A (10 DEC).
I am reading brokenthorn.com ‘s O/S development tutorials one of the tutorials, the following code is there.
http://www.brokenthorn.com/Resources/OSDev3.html
I don’t understand why this code clear 510 bytes. org, bits, cli, hlt are there in the code too. Shouldn’t it be changed to less than 510 bytes? Could it be typo or something?
Thanks.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;*********************************************
; Boot1.asm
; - A Simple Bootloader
;
; Operating Systems Development Tutorial
;*********************************************
org 0x7c00 ; We are loaded by BIOS at 0x7C00
bits 16 ; We are still in 16 bit Real Mode
Start:
cli ; Clear all Interrupts
hlt ; halt the system
times 510 - ($-$$) db 0 ; We have to be 512 bytes. Clear the rest of the bytes with 0
dw 0xAA55 ; Boot Signiture
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
It's not clearing 510 bytes, it's clearing 510 - ($-$$) bytes. Since $ is the current position, and $$ is the start of the section, it's clearing 510 - (length of the section up to that point) bytes.
This will fill the block correctly up to two bytes from the 512 byte limit, and put the signature on the two last bytes.
The boot sector is 512 bytes long, and is identified as such by the final two bytes begin set to 0xAA55. This leaves 510 bytes for the loader's actual code, which is precisely what the provided example fills when assembled. If your resulting binary isn't precisely 512 bytes long then you may need to specify a plain binary output format, though in the case of nasm this is the default setting.
In practice there are other magic bytes which need to be present for partition tables and such, and typically the first stage loader is used for little more than reading in and executing some more code.
I want to build up an ANT network (e.g. see wikipedia article ) and develop sport accessories using the iPhone 3Gs with integrated ANT Controller (used by Apple for Nike+iPod devices) to communicate with them. I need to know which ANT version the controller is (ANT or ANT+), what it's able to do (receiver/transeiver) and how I can acces the controller with software on iPhone. Until know I was able to access the serial interface and open a socket over WLAN but the only information for this topic was this one. It's one year old before the 3Gs with integrated ANT and External Accessory Framework was released. Changed that something? Are there new efforts of other groups? Every information would be helpful. Thanks.
the apple / nike footpod is not an ANT compatible device. It works with a nordic transceiver nRF2402 but with a different protocol. I reverse engineered it:
The Apple foot pod works with a nRF2402 transmitter and a PIC16F688 microcontroller.
Repetition rate: 1000ms
Number of configuration bytes: 2
Number of address bytes: 2
Number of raw data bytes: 28
Remark: the configuring is sent just before power down, i.e. 2 bytes are transmitted at that time, first 0xe7 then 0x99. The device remains active for approximately 5 seconds after a step has been detected. The device works with a simple piezo sensor to detect footsteps.
A fully transaction is made by sending 3 blocks of 9 bytes, then 11bytes then 10 bytes (almost no gap between each byte within a block, bit clock is below 2us) with a gap of 1.5ms between each block. A crosscheck with the configuration frame of the receiver shows the following:
0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc2 0xbd 0x43 0x4f 0x33
This means (see datasheet of nRF2401; configuration):
- channel 0x19 -> 2425MHz
- RF power max; 16MHz clk; shock burst; 250kbps; 1 RX channel active
- CRC enabled; CRC 16bit; address length 16bit
- Address for channel 1: 0xc2bd (high byte first)
- Address for channel 2: all 0x00
- 0xe0 -> 224 data bits for channel 1
- 0x00 -> 0 data bits for channel 2
The address length is 16 bit, and 224 bits of raw data are transmitted. The standard device address is 0xc2 0xbd anyway the data sent via link starts with the following pattern:
Address: 0xC2 1. byte of block 1
0xBD 2. byte of block 1
Data: 0x0D 3. byte of block 1
0x01 4. byte of block 1
0x47 5. byte of block 1
0xA0 6. byte of block 1
0x54 7. byte of block 1
0x22 8. byte of block 1
0xA0 9. byte of block 1
. 10.byte of block 2
. 11.byte of block 2
.
hope this helps a little
What makes you sure the iPhone (3GS) uses a nordic transceiver? It seems not visible to me on the tear down at ifixit. We assumed the BCM4325 is used for the "ANT" communication as well.
by the way, the ANT and ANT+ protocol works with full speed 1MBit/sec instead of the lower footpod speed of 250kBit/sec. The length of a frame in the nike footpod is also different compared to the ANT protocol. From a HW point of view, it is possible to run an ANT or even ANT+ protocol on an i-phone without any external HW! The transceiver is already integrated. If one had access to the nRF2401 transceiver within the i-phone writing an ANT protocol handler is a piece of cake, the ANT protocol is a pretty stupid thing and easy to implement! The ANT+ is encrypted with an 8 byte key. I guess they use the safer algorithm but I'm not sure. See also: SAFER (Secure And Fast Encryption Routine) is the name of a family of block ciphers designed primarily by James Massey on wikipedia (source code downloadable at ETH in zürich or just ask me... good luck