Does anyone know how to reset an Advanced Card Systems NFC reader type ACR1255U-J1? I've sent an escape command to it and it got stuck. When I switch the button at the top I get a purple light for LED1 and orange light for LED2 followed by red light for LED1 and no light for LED2. Any help will be appriciated.
I can see the device through Mac Terminal when it is connected through USB but it is no longer visible when bluetooth is on.
Once the ACS1255U-J1 shows the behavior you described it's basically bricked. It happens because of a stack overflow problem (no pun intended) in the readers' firmware and ACS is currently working to correct it. I've seen it happen repeatedly with very long Escape Commands like the Rewrite Master Key Command Request (36 bytes long) as well as some shorter ones. Depending on the severity of the overflow, you may be able to resurrect the reader by reflashing it with fresh firmware. You can download all the stuff you need from our site here:
http://flomio.com/ACR1255U-J1-FlashTool/
You'll need a Win7 machine to work the tool and even then it'll take a few tries to get the reader in DFU mode. If you run into issues, post support questions on our forums and we'll be happy to help.
That said your device corruption may be beyond repair. This can happen if you've wiped out the boot sector of the flash. You'll know this if the reader fails to enter DFU mode. I've been able to resurrect a few readers but found them lacking some key setting like the serial number field being gone (all zeros). But more just don't enter DFU. We're authorized distributors of ACS products so if you want to RMA your device through us let me know and we can work something out.
UPDATE: Flomio now has the ability to repair bricked ACR1255U-J1 units. You can ping us on our forums for details.
Related
I have a bluetooth keyboard that I use on a regular basis. It has a Logitech logo, but is manufactured by ZAGG and has model number Y-R0023.
I have paired the keyboard with my Ubuntu desktop and it works great.
Upon powering up my computer and keyboard, I can sometimes reconnect without having to pair again, but other times I have to remove the existing pairing and reconnect before Ubuntu can receive keystrokes.
Extra information: Ubuntu displays a bluetooth symbol as a status when it connects (regardless if it is able to receive keystrokes or not). This symbol will appear and disappear roughly every 10 seconds until the two devices are able to successfully negotiate a valid connection.
I notice that I have best success when I press 'delete-delete-enter-enter' after powering the ZAGG keyboard up. (Sometimes, just repeatedly pressing a key every second or so seems to work too.)
I am wondering if the "delete-delete-enter" keystroke combination (or some other that I haven't discovered) is recognized by the Logitech BIOS as a special sequence to help retry a paired re-connection. I'd be interested in finding out if this trick works for devices other than those made by ZAGG. Otherwise, it would help just to know if there is a reliable script I can run that calls bluetoothctl to help improve the re-connection. (I want to avoid having to enter a pairing code on subsequent connections).
ZAGG sites and Logitech ones don't say anything about this key combination. So I don't think it's recognized as a special sequence, only advice they give is to re-pair the device when it's not working.
In summary I'm sure they would include this troubleshooting option in manual and/or troubleshooting guide if it was present.
I am a beginner to arduino and trying to follow one of the videos from youtube to make a project- Master And Slave using HC-05 modules. I followed every step from that video carefully. Here's the link to the video ->
https://www.youtube.com/watch?v=BXXAcFOTnBo
For Slave Module when I type AT commands in the serial monitor nothing shows up.
I searched in Internet for the this problem and still didn't fix it. Here's What i have done:
tired restarting my pc
tried Changing arduino, At first i used arduino nano and then uno
I tried changing the baud rate to all other values and nothing happened
And there is no change in light blink, it stays on AT command mode until power is turned off and on again.
This is how is looks
Thank You For the Answer
Your problem is not actually related to arduino in any way. This tutorial is utilizing onboard USB->UART transceiver IC. So in theory you could even remove Atmel chip from the board. Its more like using module like this FT232 converter. Anyways sorry if I confused you but you can research the subject.
But anyways to the problem. Couple of questions:
Did you press reset button on module while powerin up the circuit?
Thats the way it enters to AT command mode
Did you try to reverse RX-TX lines, don't worry connecting these guys across eatch other doesn't harm your board.
(They are so often plugged in wrong..)
Did you make sure you have connected EN pin of module also. (To arduino 3.3V not 5V)
Did you triple check all connections
Try to upload simple Sketch like blinky to Arduino to make sure you are connected to USB-UART transeiver and you have correct drivers.
Make sure you upload empty sketch or remove the chip when you try to apply tutorial steps.
Change jumper wires. Sometimes cheap jumper wires are really bad quality.
I have been sometimes scratching head for long time because of broken jumper cable.
Please let me know if you have checked all of those so we can think for next step.
I am using the instructions of https://pimylifeup.com/raspberry-pi-rfid-rc522/ to learn how to read my rfid-rc522.
I installed all the things needed, and cloned from git all the files. I connected accordingly and double checked the wire.
The code in Write.py is
#!/usr/bin/env python
import RPi.GPIO as GPIO
import SimpleMFRC522
reader = SimpleMFRC522.SimpleMFRC522()
try:
text = raw_input('New data:')
print("Now place your tag to write")
reader.write(text)
print("Written")
finally:
GPIO.cleanup()
When I run it- The result stops after "Now place your tag to write" and nothing happens when I place my tag. Any help please? What's wrong here? The module gives red light meaning it is connected. Is it really connected? How do I know? Please help.
Edit: My title and tags were wrong in this question due to already saved data. I edited. :)
It can be multiple reasons why your reader is not retrieving any data:
The RFID cards that you are providing to the reader are not supported by the ISO 14443: Mifare Classic, 4K. (Some DesFire, etc...) are the cards you want to try. Source: https://en.wikipedia.org/wiki/ISO/IEC_14443
The MFRC522 is not receiving enough input voltage. Try to increase from 3.3V to 4V. I have tried with 5V months and the reader is still running perfectly, but be cautious. The safe range in NXP is from 2.5V to 3.6V. Source: https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf
The library you are using does not support IRQ (Interruption Request). This means the process of reading UIDs is high CPU consuming and low in performance. Try to use this popular library which supports interruptions: https://github.com/ondryaso/pi-rc522 . You will need to connect another wire from the IRQ pin in the MFRC522 to one GPIO pin in the Raspberry that is free and supports reading/writing operations.
Check if SPI interfaces are enable in Raspbian. Open a terminal and run:
ls -l /dev/spi
Lastly, it could be that your reader is broken. Some chinese versions do not work as they should do. Maybe you should buy another one and try more luck.
I suppose you have connected all cables in the correct way between the MFRC522 and the Raspberry Pi. Check that again.
Using uClinux we have one of two flash devices installed, a 1GB flash or a 2GB flash.
The only way I can think of solving this is to somehow get the device ID - which is down the in the device driver code, for me that is in:
drivers/mtd/devices/m25p80.c
I have been using the command mtdinfo (which comes from mtdutils binaries, derived from mtdinfo.c/h). There is various information stored in here about the flash partitions including flash type 'nor' eraseblock size '65536', etc. But nothing that I can identify the chip with.
Its not very clear to me how I can get information from "driver-land" into "user-land". I am looking at trying to extend the mtdinfo command to print more information but there are many layers...
What is the best way to achieve this?
At the moment, I have found no easy way to do this without code changes. However I have found an easy code change (probably a bit of a hack) that allows me to get the information I need:
In the relevant file (in my case drivers/mtd/devices/m25p80.c) you can call one of the following:
dev_err("...");
dev_alert("...");
dev_warn("...");
dev_notice("...");
_dev_info("...");
Which are defined in include/Linux/device.h, so they are part of the Linux driver interface so you can use them from any driver.
I found that the dev_err() and devalert() both get printed out "on screen" during run time. However all of these device messages can be found in /var/log/messages. Since I added messages in the format: dev_notice("JEDEC id %06x\n", jedecid);, I could find the device ID with the following command:
cat /var/log/messages | grep -i jedec
Obviously using dev_err() ordev_alert() is not quite right! - but dev_notice() or even _dev_info() seem more appropriate.
Not yet marking this as the answer since it requires code changes - still hoping for a better solution if anyone knows of one...
Update
Although the above "solution" works, its a bit crappy - certainly will do the job and good enough for mucking around. But I decided that if I am making code changes I may as well do it properly. So I have now implemented changes to add an interface in sysfs such that you can get the flash id with the following command:
cat /sys/class/m25p80/m25p80_dev0/device_id
The main function calls required for this are (in this order):
alloc_chrdev_region(...)
class_create(...)
device_create(...)
sysfs_create_group(...)
This should give enough of a hint for anyone wanting to do the same, though I can expand on that answer if anyone wants it.
I want to use a SensorTag 2 so that it is sitting there broadcasting it's data (and, critically connectable over bluetooth) from when it's turned on to when\if I ever turn it off. Out of the box, the tag is set to only advertise over Bluetooth for a few mins which means that when the connection eventually fails or when the device connected to the tag boots etc etc you can't connect again without physically visiting the tag and resetting it.
I see there is firmware that the myWeatherCenter people have created that lets the tag work as a weather station by basically setting it to advertise indefinitely... frustratingly though their firmware is only the sensortag version 1 :-(
I've researched on and off for months and months now and nothing coming back.. suggesting either nobody else wants this, there is a really simple solution everyone one else knows about or ...? I can't even see anyone else asking this question really... which is worrying.
Does anyone have a firmware file that sets this setting for the sensortag 2 or know how to modify the firmware to set this setting?
It is definitely possible to change the SensorTag 2/CC2650 platform so that its behavior suits your use case. I - for example - currently use a custom firmware doing pre-processing of sensor readings on the SensorTag and sending data directly in the advertisement message indefinitely (of course you have to tweak intervals and payload to get a decent battery life).
I assume you have CCS and the sources (SensorTagApp and SensorTagStack) at hand?
I recommend flashing the current SensorTagStack first, if not done yet (though I'm not yet on 2.2 myself).
In the SensorTagApp project under Application you find SensorTag.c. In there you should change:
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_LIMITED
to
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL
This is the usual advise and might already do the trick.
In my firmware I also changed (in SensorTag.c, in the SensorTag_init function):
uint16_t advertOffTime = 0;
to
uint16_t advertOffTime = 1;
Please try these changes and get back to me. If that wasn't enough I will do a more thorough comparison of the stock firmware and my custom firmware. I also recommend the more specific ti Bluetooth low energy forum.
You could find the workflow for a complete solution and the firmware for continuous advertising which I created recently, at Sensortag CC2650STK Custom Firmware Modification&Download Workflow (Continuous Advertising) using Code Composer Studio, Debugger DevPack and Flash Programmer 2 software