I am trying to write to a board control register on a PMC A/D card attached to a PCI board with 4 DSPs on it. The A/D card sits on the PCI local bus and I know the values for its BARs, but I still cannot seem to write to the board control register from either the host PC or the DSPs.
So, my question is where exactly would the base address of the device be located? Is it in the RAM always, or is there not a specific location the PCI device is mapped to? I would like to initialize the board control register (which is supposed to be at 0x00 offset from its base) and be able to see that it is being set to the expected initialization value.
Base address for the board is assigned to the board by the operating system on start-up.
OS does a scanning of the PCI devices in the board and allots each device a non-conflicting address range.ie. OS writes the BAR during startup. BAR is a register (Read/Writable) which is implemented inside the PCI card. OS uses configuration cycles to write the to the BAR.
Related
I'm trying to implement the Apple Notification Center Service using an Adafruit Feather 32u4 Bluefruit LE to be able to receive notifications from my iPhone to the Feather board, sending them to my PC over Serial connection and dealing with them with some software that I wrote.
I set up the ANCS service and characteristics using the AT+GATTADDSERVICE and AT+GATTADDCHAR commands but when I try to make the device discoverable and to advertise the use of the ANCS service the device won't become discoverable.
This is the command that I use:
AT+GAPSETADVDATA=02-01-06-11-06-79-05-F4-31-B5-CE-4E-99-A4-0F-4B-1E-12-2D-00-D0
Where:
0x02: is the byte length of the first message in the payload
0x01: is the 'Data Type Value' and indicates that this is a 'Flag'
0x06: indicates the flag LE General Discoverable Mode without BR/EDR support
0x11: is the byte length of the second message (0x11 is 17 bytes in decimal, 1 for the type of "message "Incomplete List of 128-bit Service Class UUIDs", 16 bytes for the UUID of ANCS)
0x06: is the 'Data Type Value' for "Incomplete List of 128-bit Service Class UUIDs"
0x7905F431B5CE4E99A40F4B1E122D00D0: is the UUID for ANCS.
When I use the above command though, the device won't become discoverable. Do you know why?
While trying to troubleshoot the problem I noticed that if I try to advertise different services like an heart rate service and a device information service the device does become visible from other devices. This is the command that I used:
# Advertise as Discoverable and BLE only with 16-bit UUIDs 0x180D and 0x180A
AT+GAPSETADVDATA=02-01-06-05-02-0d-18-0a-18
Do you know why the device won't become visible when trying to advertise the ANCS service?
Thank you!
P.S. I'm new to the bluetooth protocol, sorry.
Have a look at the specification of the ANCS you provided. It states:
Only one instance of the ANCS may be present on an NP. Due to the nature of iOS, the ANCS is not guaranteed to always be present. As a result, the NC should look for and subscribe to the Service Changed characteristic of the GATT service in order to monitor for the potential publishing and unpublishing of the ANCS at any time.
Further down you find figures that show that your iPhone is the NP and it is the one that might implement the ANCS.
Your Feather board would be the Central and is supposed to look for the service and connect to it. As #Paulw stated in the comments you have it the wrong way around.
I'm currently working on a PCIe-based Intel network card driver for my OS development project. While the driver seems to be working well, as soon as I enable INTA (IRQ 16, using the I/O APIC) I keep getting a flood of interrupts which completely blocks my kernel. These are not caused by the network card (Interrupt Cause Register is all zeroes), except in very few cases where the card actually received a packet.
Things I have tried:
Test other IRQ trigger settings - level-triggered on "low" should be correct, since in other cases nothing happens at all (network card interrupts should work).
Disable all other PCIe devices: I tried writing 0x0400 into each device's PCIe cfg space command register (set the interrupt disable flag, clear all other flags); I only excluded the network card, the video card and bridge devices. Although that operation succeeds, I am not entirely sure that this really disables the given devices, since those interrupts still occur.
Is writing 0x0400 to the command register the proper way to completely disable a PCIe device?
A PCI card can have some memory associated with it (either mapped to memory space or mapped to IO space).
Now say we have a PCI Ethernet card (and it is using memory-mapped IO), the Ethernet card will have some memory as a buffer to put data to send down the wire in, and whenever the Ethernet driver wants to send the data down the wire, it can ask the Ethernet card to do that.
Now I assume that a part of the mapped memory for the Ethernet card is a "command register", and when you write for example the string "send it" to this command register, the Ethernet card will send the buffer down the wire.
Now my question is, how does the Ethernet card knows that the memory for the control register has been written to? does the Ethernet card polls the memory content for the control register, or is there some mechanism that is used to send a signal automatically to the Ethernet card whenever the memory address for the control register is written to (so kind of like an interrupt, but in the opposite direction)?
The address range of memory-mapped IO for a PCI card is controlled by the Base Address Registers (BARs) of the PCI device. When the CPU accesses a memory address within the range of a BAR, the memory access is routed directly to the device (along with the data, if it is a write operation), instead of being routed to memory. When the PCI device receives the memory access it immediately updates the designated control register. If the MMIO access is a read operation, the device responds to the CPU with the appropriate value.
MMIO lets you use load and store instructions instead of IN and OUT instructions, but the device still sees commands, not just memory accesses.
That's why it's MMIO, not just memory-mapped device memory.
I have a hidden service/characteristic on a BLE device, that only becomes visible if you send the "right" command to another characteristic. However, if I stay connected, and just call "discoverServices:nil" or "discoverServices:service-i-care-about", it won't find it once enabled.
I changed my firmware to make the device not hide the service on disconnection (which is what I would want), but to stick around, and I know the service is getting enabled, because I can reconnect to device, and the service shows up.
I don't want to do this, because the whole point of hiding the service is you have to send the right command to enable the service (for the record, it is a firmware update service provided by a MCU vendor, so I can't change the service to be one of "mine" or put any security around the service itself)
Is this the intended bluetooth behavior? Or is iOS perhaps caching something and I have to do something to make it not get the cached values?
iOS caches any discovered peripheral and the corresponding services and characteristics for performance reasons. If you need to change the GATT table of your peripheral at any given time you have two options to tell the centrals:
tell the central via the Services Changed characteristic
change the mac address of your peripheral (not recommended but some chipset makers use this workaround, e.g., NordicSemi in the BLE bootloader)
We came across this problem as well because we need to hide the firmware update service of our embedded device until we jump to the bootloader.
I'm aware that a NIC in promiscuous mode is able to detect packets of wifi enabled devices looking for networks and obtain their MAC addresses, is it still possible to obtain the MAC Address of a device connected to a wifi access point?
Cheers.
Yes, it is possible when the AP is using WEP or no encryption at all. APs using WPA or WPA2 however will encrypt the whole header.
A WEP Wifipackage has the following structure:
Address Fields Depending upon the frame type, the four address fields
will contain a combination of the following address types: BSS
Identifier (BSSID). BSSID uniquely identifies each BSS. When the frame
is from an STA in an infrastructure BSS, the BSSID is the MAC address
of the AP. When the frame is from a STA in an IBSS, the BSSID is the
randomly generated, locally administered MAC address of the STA that
initiated the IBSS.
Destination Address (DA). DA indicates the MAC address of the final
destination to receive the frame.
Source Address (SA). SA indicates the MAC address of the original
source that initially created and transmitted the frame.
Receiver Address (RA). RA indicates the MAC address of the next
immediate STA on the wireless medium to receive the frame.
Transmitter Address (TA). TA indicates the MAC address of the STA that
transmitted the frame onto the wireless medium.
If you want to grab MAC addresses it would be possible to just sniff them from the packages sent in on the different Wi-Fi networks (Using WEP or No encryption).