I want to jump from the application code to the bootloader when i receive a FW upgrade command from the PC.
The bootloader checks 2 conditions-valid application and a external trigger.
In my case, i do not want to use a switch press a s an external condition.
Can i set a GPIO Pin(as a condition for external trigger) and then jump to the bootloader without any reset?
Is there any other register that can be set in PIC32 for this implementation which can retain its value even on reset? Do we have a sample code for that?
i want to check the register value in the bootloader code and then proceed with the fw upgrade process.
Any other idea for PIC32 MCu will be accepted.
This is easy..
asm("reset");
Will get you back to address 0x0 and you can check the RCON register value for a Software reset and trigger the FW update on that. I've done it before and it works great. For the GPIO trigger, simply setup an INT pin with an interrupt and have it trigger the asm("reset"); instruction. As for the way to check a variable, in your code setup an non volatile area and you can read write from it. http://www.microchip.com/forums/m721413.aspx
Related
I have 3 monitors, but I don't need them all turned on all the time. I can just shut them down with power button, but I want to use their standby mode, like Windows does when we let PC idle for a while - it shuts down monitors, HDD, etc.
But of course, I wanna keep using PC and let just that monitor on standby. Others must remain on and that one doesn't wake up even with me using PC.
Is it possible to do that? It would be great to have a shortcut like Winkey+1, 2, 3 etc to shut down and wake up each monitor.
An existing app with this feature is not likely to exist, but is there a Windows API function that can control monitor state, for each monitor in a MultiMonitor system?
The display control panel applet calls SetDisplayConfig to start or stop forced projection on a particular target
You can probably use MS Detours or some other API hooking tool to inspect the usage pattern of the API while using the applet to adjust display settings.
You'll want to try Display Fusion. You should be able to do what you're asking for using Monitor configurations.
I know I'm late on this but use DDC to control your display. You can easily create hotkeys that send a command via DDC to the display to turn-off. This would be equivalent to turning off the display using the button. Works like a charm for me. The only trick is that DDC command specs vary across monitor manufacturers but its not hard to find the right codes to send with the help of google.
Ready made tools also exist for this; search for anything that is related to DDC or EDID and you should find.
Be aware though that this does not remove the display from Windows which means that apps may find their way onto displays that are off and you will be looking for them.
I am writing a device driver where I need to read and write to a lot of registers. Is there any way I can tell if the operation as been successful? Currently we have a driver for some old HW but all of the driver functions are void and we just assume the operation was successful.
Are there any known tips or design patterns which would be good to follow when making a device driver?
Thanks,
You could do any of the following which suits you :
1) just write the register and immediately read back the same register.
2) create a function which outputs the value of each register when called.
Just make sure some registers might reset when read from it ( This might cause your code to malfunction )
I am currently working on a hobby OS, specifically the ATA driver. I am having some issues with PIO data-in commands with interrupts. I am trying to execute the READ MULTIPLE command to read multiple sectors from the drive, block by block, with an interrupt firing for each block.
If I request a read of 4 blocks (1 sector per block). I expect to get 4 interrupts, one for each data block. Upon receiving the 4th interrupt I can identify that I've transferred all data and update my request structure accordingly. However, in VirtualBox I've found that after the last data block has been transferred I received yet another interrupt (STATUS = 0x50, READY, OVERLAPPED MODE SERVER REQ). I can simply read the STATUS register then to clear it, but I don't think I should ever receive the 5th interrupt according to the specs.
So what is the proper way acknowledge an interrupt issued by an ATA device?
In this example I issue a READ MULTIPLE command, and then my ISR does the following:
disables CPU interrupts, sets nIEN
Read a single data block (not sector!) fro the DATA register,
If all data has been read, read the STATUS register to clear the 'extra' interrupt
Exit by clearing nIEN, and sending EOI's to both the master and slave PICs
The ATA specs for the PIO data-in command protocol don't indicate that you need to read the status register. From that I assumed that when I receive an interrupt all I have to do is follow the protocol and finish by sending the EOIs to the PICs. As for the setting/clearing of nIEN, in dealing with VirtualBox I've found that if I don't do this I don't receive any interrupts past the first one. So I set nIEN when entering the ISR, then clear it before I leave. I'd think that wouldn't have any effect, but it must be related to reading/writing that specific register.
This always happens to me, I post a question I've been struggling with, only to find the answer myself shortly after.
The ATA-6 spec I've been referencing has this one line in the PIO data-in section (9.5):
When in this state, the host shall read the device Status register.
With ATA the Status register has a side-effect: it clears a pending interrupt. I knew this, but I didn't correctly read this part before. It doesn't mention why you should read the register, it just states it exactly as above.
The important part is how this works with the interrupt handler. After issuing a PIO data-in command, once the INTRQ is asserted, you simply read the Status register once to clear the interrupt, then continue to processes the interrupt and return as normal (just sending EOIs to the PICs.) What had me confused is that none of the documentation I read mentioned exactly how this should work with interrupts (receive an INTRQ, read Status, processes interrupt.) Most online guides only deal with polled IO.
This is one of the difficulties with low-level programming, key details, such as needing to read the Status register in the ISR, are often glanced over. This one was left as a single line in the protocol description. Call me picky but I just would have expected more emphasis on this point.
This question already has an answer here:
How are data breakpoints created?
(1 answer)
Closed 1 year ago.
Requirements:
I need to generate an interrupt, when a memory location changes or is written to. From an ISR, I can trigger a blue screen which gives me a nice stack trace with method names.
Approaches:
Testing the value in the timer ISR. Obviously this doesn't give satisfying results.
I discovered the bochs virtual machine. It has a basic builtin debugger that can set data breakpoints and stop the program. But I can't seem to generate an interrupt at that point.
bochs allows one to connect a gdb to it. I haven't been able to build it with gdb support though.
Other thoughts:
A kind of "preview instruction" interrupt that triggers for every instruction before executing it. The set of used memory-writing instructions should be pretty manageable, but it would still be a PITA to extract the adress I think. And I think there is no such interrupt.
A kind of "preview memory access" interrupt. Again, I don't think its there.
Abuse paging. Mark the page of interest as not present and test the address in the page fault handler. One would still have to distinguish read and write operations and I think, the page fault handler doesn't get to know the exact address, just the page number.
See chapter 16 in Intel's Software Developer's Manual Volume 3A. It gives information about using the debug registers, which provide support for causing the debugger exception when accessing a certain address, among other things. The interrupt will be triggered after the instruction which caused it. Specifically, you will have to set one of dr0-dr3 to the address you want to watch, and dr7 with the proper values to tell the processor what types of accesses should cause the interrupt.
Is it just because the EFLAGS register works like a switch? So when it's active, the interrupt is enabled, otherwise, it's not?
Say, in a Java program it would be something like,
while (switch != 0){
keepRunning;
}
Stop;
The core saves EFLAGS in the interrupt stack frame in order that the interrupted task can be resumed later. EFLAGS is part of the bare minimum machine state saved by the core in the stack frame, which also includes the instruction pointer (EIP), code segment (CS) and usually the user-mode stack pointer (ESP). When the interrupt service routine completes (with the IRET instruction), the core restores EFLAGS and the rest of the registers in the stack frame.
The basic philosophy here is that a task can execute without worry that any random interrupt will suddenly stomp on registers. It's the only sane approach.
I believe a reason for this is simply that the registers are modified by virtue of taking an interrupt. Namely the IE (interrupt-enable) flag will be cleared. If the CPU didnt push the flags, it wouldnt be able to modify the flags and would require extra state and extra instructions to get this hidden state.