UPDATE:
I pinpointed where the problem is coming from. To avoid any complication, I'm using ScanNetwork example, so I don't even have to put in SSID. The code stops functioning on the board as soon as it hits WiFi.status().
I have a Serial.println before and after it tries to get a WiFi.status(), the serial.println after wasn't performed, and of course, I'm still not connected.
I've downloaded fresh copy of the code, and the situation remains the same. I've really run out of idea....
I'm using the official arduino wifi shield, and I have the following code:
status = WiFi.begin([ssid],[pass]);
Serial.println(status);
Status is neither WL_CONNECTED nor WL_IDLE_STATUS, which are the two possible responses outlined in the official reference http://arduino.cc/en/Reference/WiFiBegin
Status is the number 4.
and of course, I couldn't connect to wifi.
What is this????
I've pressed the reset button a million times, is there a more powerful factory restore button?
I've figured it out.
Apparently, there's a jumper, that when you put it in, it'll kick the shield into a DFU-mode that enables reprogramming. And the shield wouldn't be present as a result.
According to WiFi.h The return values of the begin() functions (all three of them, one for each security scheme) are ints. It is not stated outright on this function but I believe that just as with the status() function the return type is a wl_status_t. wl_status_t is an enum declared in wl_definitions.h As:
typedef enum {
WL_NO_SHIELD = 255,
WL_IDLE_STATUS = 0,
WL_NO_SSID_AVAIL,
WL_SCAN_COMPLETED,
WL_CONNECTED,
WL_CONNECT_FAILED,
WL_CONNECTION_LOST,
WL_DISCONNECTED
} wl_status_t;
So your 4 is WL_CONNECT_FAILED. Probably not surprising to you since, you know, you connection failed.
The hobbiest's debugger, AKA reset button, will only do so much. Printing the status was a good start. Be sure you are using the right flavor of begin() for you security type, you seem to be using the one for WPA. Consider shutting off you router's security completely (if safe to do so in your area), or using a spare router, to test the ability of the shield to communicate at all. Also this may sound obvious but check for a misspelling of the SSID.
Related
I am a bit new here, English is not my native, so I am sorry for any possible misspelling.
I have a very odd problem - my Xiaomi Mi Surface Display 34" (XMMNTWQ34 model) monitor buttons act really strange - instead of calling the monitor OSD, pressing any of 4 present buttons tries to switch to another possible input source (this is even not their function!), but no luck: just 3 seconds of the black screen and it turns back to the initial image. Let me explain how I got into this.
I have a monitor named before, which has 4 input ports: 2 DP and 2 HDMI. There is a PC always connected to the monitor via the DP interface (DP1 to be exact). Today I tried to connect a second PC via HDMI to the HDMI1 port. It went totally good, I was able to switch between PCs using a monitor OSD. But I thought it was too long and complicated to press a dozen buttons on OSD just to change an input source, so started to google any other programmatical methods of doing such thing.
Some fact: there are no drivers for this monitor on the Internet (it actually works at full 3440x1440#144 Hz resolution/refresh rate via DP interface without any trouble, but Windows sees it as "Generic PnP Monitor", so I see no way to fix it without a relevant driver).
I have found that any VESA-compatible monitor has the 0x60 parameter, which means exactly "input source", so altering the value of this parameter switches the input source without the need to call an OSD. I have found that the possible values of this 0x60 parameter for my monitor provided by several utilities are: 0x0F, 0x10, 0x11, and 0x12. But setting any of these values got me no luck - the screen just flashed black and nothing more. Moreover, those utilities showed that the current value of the 0x60 parameter was 0x07 - described as "S-Video 1" input source, and it did not change at any made tries. But my monitor does not even have such input ports!
But I discovered a total disaster a bit later - when I tried to switch the input source via OSD, I was not able to call it - any of the 4 buttons on the monitor was causing a black flash and nothing more! So OSD is now totally unavailable! This is madness. I can't enter the OSD, I can't change the input source without turning off any one of 2 connected PCs, I can't do anything which is supposed to be made via OSD. Rebooting and reattaching of every possible thing has no effect - even with 2 PCs being connected to monitor and waiting to enter a BIOS password (no OS loaded whatsoever): pressing any button on the monitor causes only black flash and nothing more, no OSD called. I guess this is a strictly monitor firmware issue because the OSD worked well until yesterday.
I have absolutely no idea how to solve this, I googled this all day long, but no luck. System restore did not change anything. Please help. Thank you all very much.
Same issue after using ControlMyMonitor App. At the time being, i didn't found any solution to get the OSD back. And I didn't found any solution to factory reset the monitor, I don't know if it's possible.
I strongly discourage users to use any kind of VESA com application on this Xiaomi 34 monitor !
Now, the best solution in order to switch inputs, is to disconnect or shutdown one of the computer connected, ans it will switch automaticaly to the only one remaining. (Or use a VESA script...)
I have a board with an XMC1400 MCU on it. It is a custom board with LEDs and buttons and so on.
So I accidentally add a '''XMC_SCU_RESET_AssertMasterReset()''' line at the beginning of the code... This function cause xmc to reset but it doesn't just reset the program counter, it also clears everything and ends the debug connection. And since it happens so quickly I cannot reconnect before it resets again. For the one who doesn't know, when you load a program to the xmc, it gets written to the flash, and once it's loaded it will always run with power up.
I know in some boards there are some pins used to clear to board when shorted but there is no such a thing in this one.
There are however several bootstrap loaders(can and uart). But they are disabled by a flash parameter called BMI. I don't have much hope but is there a way to rescue this processor?
Thanks!
I'm working on a basic sketch for an Adafruit Huzzah which uses the Adafruit IO MQTT library. This is put together by copy/pasting from various sources and examples, and mostly works - but there's one thing I can't figure out.
Right now, I'm using a line of code which fires off a handler every time a new message is received via the feed I'm subscribed to:
group->onMessage("daniel", handleMessage);
This is fine, and does what I need it to do for values which are updated.
What I want to do, however, is grab the last known value on the feed during the setup() routine, rather than having to wait for a new value to come though.
In MQTT parlance, I believe this is known as retained messages, which I think Adafruit IO has on by default, but I don't know how to grab these values during the startup() process.
Can anyone help me out?
(If you're interested, here's my code so far: https://github.com/LimeBlast/family-box/blob/master/family-box.ino)
Short answer is you don't... do anything.
Retained messages are delivered just the same as normal messages (via the onMessage callback), they are just delivered as soon as you subscribe to the topic.
I also had this problem. Here is the full explination
The get() function wil ask the Adafruit servers to resend the last value of the feed to this client only. When the value is received, the handler will be executed.
exampleFeed->get();
Seeing as I've just found the answer to the question I was asking, I figured it only right I post it here.
The command I was looking for, after having setup the feed, was ->get(), as shown in this example.
I'm quite new to working with Arduino/GSM and have had problems getting basic HTTP functionality working. I am currently facing multiple problems - one being that the 3G shield I am working with (SIMCOM SIM5216A) does not seem to want to connect to a carrier! :(
However, the problem I would like to focus on for this question is that Phone Functionality - designated through the AT+CFUN command - does not seem to be maintained through power cycles. Additionally, sometimes after modifying the CFUN, the modem will run a soft reset.
Here is the command I have been using to modify the phone functionality of the modem:
AT+CFUN=1,0
I am under the impression that the second parameter should stop it from running a soft reset.
I have attempted to save the AT configuration by following advice in this question's accepted answer - here is the output from power on:
START
+STIN: 25
+STIN: 25
+CPIN: READY
SMS DONE
PB DONE
AT+CFUN=1,0
OK
AT&W
OK
However, whenever I next reset, I will get the following:
AT+CFUN?
+CFUN: 4
OK
So, my question is how can I save the CFUN configuration to be consistent between power cycles? (If you happen to be able to offer advice on why I can see medium-strength signal but cannot connect to an operator network, any advice would be welcome there too, however that is not the focus of this question)
With thanks,
BadDevH.
Exactly what that is saved with AT&W is a rather muddled, see this answer for details. However, regardless of that, the AT+CFUN command is controlling such a dynamic behaviour that I cannot imagine any manufacturer ever that has saved this with &W. Think more of CFUN more like setting a fixed cruise control speed while driving a car. There is no way the car will continue with the speed from last time when started.
For normal phones the default behaviour is value 1 - full functionality - because that is the very core functionality of what they do1, but for a GSM module shield, I am guessing that the default behaviour is set to no radio in order to save power, so it stays off until you need it at which point you need to explicitly turn it on.
1
And even in the case of no sim card present, it shall still be able to make emergency calls.
Can someone please explain how the Arduino bootloader works? I'm not looking for a high level answer here, I've read the code and I get the gist of it.
There's a bunch of protocol interaction that happens between the Arduino IDE and the bootloader code, ultimately resulting in a number of inline assembly instructions that self-program the flash with the program being transmitted over the serial interface.
What I'm not clear on is on line 270:
void (*app_start)(void) = 0x0000;
...which I recognize as the declaration, and initialization to NULL, of a function pointer. There are subsequent calls to app_start in places where the bootloader is intended to delegate to execution of the user-loaded code.
Surely, somehow app_start needs to get a non-NULL value at some point for this to all come together. I'm not seeing that in the bootloader code... is it magically linked by the program that gets loaded by the bootloader? I presume that main of the bootloader is the entry point into software after a reset of the chip.
Wrapped up in the 70 or so lines of assembly must be the secret decoder ring that tells the main program where app_start really is? Or perhaps it's some implicit knowlege being taken advantage of by the Arduino IDE? All I know is that if someone doesn't change app_start to point somewhere other than 0, the bootloader code would just spin on itself forever... so what's the trick?
Edit
I'm interested in trying to port the bootloader to an Tiny AVR that doesn't have separate memory space for boot loader code. As it becomes apparent to me that the bootloader code relies on certain fuse settings and chip support, I guess what I'm really interested in knowing is what does it take to port the bootloader to a chip that doesn't have those fuses and hardware support (but still has self-programming capability)?
On NULL
Address 0 does not a null pointer make. A "null pointer" is something more abstract: a special value that applicable functions should recognize as being invalid. C says the special value is 0, and while the language says dereferencing it is "undefined behavior", in the simple world of microcontrollers it usually has a very well-defined effect.
ATmega Bootloaders
Normally, on reset, the AVR's program counter (PC) is initialized to 0, thus the microcontroller begins executing code at address 0.
However, if the Boot Reset Fuse ("BOOTRST") is set, the program counter is instead initialized to an address of a block at the upper end of the memory (where that is depends on how the fuses are set, see a datasheet (PDF, 7 MB) for specifics). The code that begins there can do anything—if you really wanted you could put your own program there if you use an ICSP (bootloaders generally can't overwrite themselves).
Often though, it's a special program—a bootloader—that is able to read data from an external source (often via UART, I2C, CAN, etc.) to rewrite program code (stored in internal or external memory, depending on the micro). The bootloader will typically look for a "special event" which can literally be anything, but for development is most conveniently something on the data bus it will pull the new code from. (For production it might be a special logic level on a pin as it can be checked nearly-instantly.) If the bootloader sees the special event, it can enter bootloading-mode, where it will reflash the program memory, otherwise it passes control off to user code.
As an aside, the point of the bootloader fuse and upper memory block is to allow the use of a bootloader with no modifications to the original software (so long as it doesn't extend all the way up into the bootloader's address). Instead of flashing with just the original HEX and desired fuses, one can flash the original HEX, bootloader, and modified fuses, and presto, bootloader added.
Anyways, in the case of the Arduino, which I believe uses the protocol from the STK500, it attempts to communicate over the UART, and if it gets either no response in the allotted time:
uint32_t count = 0;
while(!(UCSRA & _BV(RXC))) { // loops until a byte received
count++;
if (count > MAX_TIME_COUNT) // 4 seconds or whatever
app_start();
}
or if it errors too much by getting an unexpected response:
if (++error_count == MAX_ERROR_COUNT)
app_start();
It passes control back to the main program, located at 0. In the Arduino source seen above, this is done by calling app_start();, defined as void (*app_start)(void) = 0x0000;.
Because it's couched as a C function call, before the PC hops over to 0, it will push the current PC value onto the stack which also contains other variables used in the bootloader (e.g. count and error_count from above). Does this steal RAM from your program? Well, after the PC is set to 0, the operations that are executed blatantly "violate" what a proper C function (that would eventually return) should do. Among other initialization steps, it resets the stack pointer (effectively obliterating the call stack and all local variables), reclaiming RAM. Global/static variables are initialized to 0, the address of which can freely overlap with whatever the bootloader was using because the bootloader and user programs were compiled independently.
The only lasting effects from the bootloader are modifications to hardware (peripheral) registers, which a good bootloader won't leave in a detrimental state (turning on peripherals that might waste power when you try to sleep). It's generally good practice to also fully initialize peripherals you will use, so even if the bootloader did something strange you'll set it how you want.
ATtiny Bootloaders
On ATtinys, as you mentioned, there is no luxury of the bootloader fuses or memory, so your code will always start at address 0. You might be able to put your bootloader into some higher pages of memory and point your RESET vector at it, then whenever you receive a new hex file to flash with, take the command that's at address 0:1, replace it with the bootloader address, then store the replaced address somewhere else to call for normal execution. (If it's an RJMP ("relative jump") the value will obviously need to be recalculated)
Edit
I'm interested in trying to port the bootloader to an Tiny AVR that doesn't have separate memory space for boot loader code. As it becomes apparent to me that the bootloader code relies on certain fuse settings and chip support, I guess what I'm really interested in knowing is what does it take to port the bootloader to a chip that doesn't have those fuses and hardware support (but still has self-programming capability)?
Depending on your ultimate goal it may be easier to just create your own bootloader rather than try to port one. You really only need to learn a few items for that part.
1) uart tx
2) uart rx
3) self-flash programming
Which can be learned separately and then combined into a bootloader. You will want a part that you can use spi or whatever to write the flash, so that if your bootloader doesnt work or whatever the part came with gets messed up you can still continue development.
Whether you port or roll your own you will still need to understand those three basic things with respect to that part.