According to Gameboy Programming Manual,
HALT mode is canceled by the following events, which have the starting addresses indicated.
A LOW signal to the /RESET terminal Starting address: 0x0000
The interrupt-enable flag and its corresponding interrupt request flag are set
IME = 0 (Interrupt Master Enable flag disabled)
Starting address: address following that of the HALT instruction
IME = 1 (Interrupt Master Enable flag enabled)
Starting address: each interrupt starting address
Assume a program enters HALT mode with Interrupt Master Enable flag enabled IME = 1 and Interrupt Enable disabled for any interrupt 0xFF0F = 0, what would happen? What is the expected behaviour on the actual Gameboy device?
I am not sure if I understand your question right, but anyway:
According to the cited manual, the IE (interrupt enable) register, address FFFF, determines which one of the 5 interrupt types are enabled. Only those set to 1 will be accepted if IME (interrupt master enable) ist set to 1.
The IF (interrupt flags) register, address FF0F, provides merely information which interrupts are requested.
So, if a program is in the HALT state with IME = 1, any interrupt is accepted that is enabled in IE. Of course, somebody had to generate the interrupt(s) which would be indicated by a (or more) 1 in the IF register.
EDIT:
Maybe this answers your question now:
If the program enters HALT mode, Interrupt Master Enable is enabled (IME = 1), but all specific interrupt types are disabled (IE = 0), no interrupt will be accepted, and HALT mode is not left. This is the expected behavior on the device.
Related
Assume there are two boards with stm32 micro-controllers which are connected to each other with rs-485 (each board has a uart-to-rs485 transceiver). This is the connection diagram and the accessible ports:
I want to be able to re-program each board separately using rs-485 wires that are available. Using st system bootloader and boot0 pin is not an option because it requires changing the PCB and re-wiring the system.
So I need to write my own custom bootloader. What I intend to do is to separate the flash memory of the B-1 MCU into three parts:
20KB for bootloader
120KB for B-2 application (as kind of a buffer)
360KB for B-1 application (bootloader jumps to this part after finishing boot mode)
and for B-2, two partitions:
20KB for bootloader
100KB for main application
and using the UART interface of B-1, I can load the .hex files to the specified flash area and tell the MCU what to do with it (either use it as it's own main app or send it to B-2).
Here is a brief algorithm for the bootloader:
// B1: starts from bootloader
for (5 seconds) {
// check for the boot command from UART
if (command received) {
// send boot and reset command to B-2 and receive ack
// start the boot mode
while (boot mode not aborted) {
// receive command packet containing address
if (command == header && address == B1) {
// prompt for the main .hex file and store it in B-1 partition
} else if (command == header && address == B2) {
// prompt for the main .hex file and store it in B-2 partition
// send header and the app to B-2 using rs-485 port
} else if (command == abort) {
break from while loop
}
}
} else {
// do nothing
}
}
// jump to main application
Now I have 2 concerns:
Since there is no gpio connection between B-1 and B-2 to activate boot mode for B-2, is it possible for B-2 board to set a flag in flash memory outside of it's main application area to check for it and use it as a boot mode activation flag?
Is it possible to write the stream of data directly from uart input to the flash memory area of each application? like this:
// Obviously this address is outside the flash area of the current bootloader running
uint8_t appAddress = B2_APP_FLASH_MEMORY_PARTITION_START_ADDRESS;
for (i from 0 to size_of_app) {
hal_uart_receive(&uartPort, appAddress + i, 1, timeout);
}
Since there is no gpio connection between B-1 and B-2 to activate boot mode for B-2, is it possible for B-2 board to set a flag in flash memory outside of it's main application area to check for it and use it as a boot mode activation flag?
I am not sure that you are suggesting, or how your suggestion will solve the problem. Ideally you would have a means form B1 of directly resetting B2 via its /RESET line, but failing that if it is loaded with an application that accepts a reset command or signal over the RS-485, then you can then have it issue a soft-reset to start the bootloader. On Cortex-M devices you can do that through the NVIC.
If you need to communicate information to the B2 bootloader - perhaps to either invoke an update or to bypass that and boot the application, you need not program flash memory for that, you can simply write a boot command or signature via a reserved area of SRAM (best right at the top) that is not initialised by the runtime start-up (or the content of which you capture before such initialisation). Content in SRAM will survive a reset so long as power is maintained, so it can be used to communicate between the application and the bootloader - both ways.
This is of course a bootstrap issue - what if there is no application loaded to accept a reset command, or the application is not valid/complete (programming interruption). Well the relocated application area will have its vector table including its initial-SP and reset vector right at the start. In your bootloader when the first 8 bytes of the image are received, you hold them back and do not program that area until the rest of the image is written. By programming the reset vector last, if the programming is interrupted, that location will not be a valid address. The bootloader can validate it (or check if it is in the erase state) and if not valid/written, it can wait indefinitely for an update or simply reset to repeat the update polling. Be aware of a bit of an STM32 gotcha here though - most parts erase flash to "all-ones" (0xFF) state, some however (STM32Lxx parts) erase to "all-zeroes". Of course you couls simply check for 0x00000000 or 0xffffffff since neither would be a valid start address, or explicitly check the range.
Is it possible to write the stream of data directly from uart input to the flash memory area of each application? like this:
Yes, but remember that on STM32, normally the code is executing from the same flash memory you are trying to program and that the bus stalls during flash write and erase, such that if you are executing from flash, execution halts. For page erase, that can be several milliseconds - for parts with large pages, several hundred milliseconds even. That may mean that you fail to read characters on the UART if you are using polling or interrupt.
You can overcome this issue by protocol design. For example if you use a packet protocol where the last packet must be acknowledged before the next one is sent, you can use that as a flow control. Once you have collated a block of data to be written, you simply delay the acknowledgement of the last packet until after you have erased and/or written the data to flash. XMODEM-1K is a suitable protocol for that and despite its flaws its simplicity and support in common terminal emulator applications make it a good choice for this application.
Now all that said, you can increase the flash available to B1 by not buffering the image for B2 on B1 at all and simply implement a bi-directional pass-through such that the input on the UART of B1 is passed directly to the B1 RS-485 output, (surely also a UART so your port naming is ambiguous), and B1 RS-485 input passed directly to the UART output. That way B1 becomes "transparent" and the update tool will appear to be communicating directly with B2. That is perhaps far simpler and faster, and if the bootloader is "fail-safe" as described above, will still allow retries following interruption.
The pass-through function might be part of B1's application or a "mode" of the bootloader. The pass-through mode might be invoked by a particular boot command or you might have the application pass a "boot mode" command via the SRAM mechanism described earlier.
In either case ideally you would have identical bootloader code on both B1 and B2 for simplicity and flexibility. There is no reason why that should not be the case; they are both receiving the updates over UART.
I'm using the bxCAN peripheral of an STMF3 uC in an environment where
1.) it is essential that the node is detached from the network once the REC/TEC has reached the warning level (waiting for the bus-off condition is not an option)
2.) the baud rate of the host network is unknown
3.) the connection might be sporadic as the node is connected by the user
Due to 1.) the STM32 HAL CAN driver is used in IT mode and whenever the called with the EWG flag set, the error callback shuts down the transceiver and deinitializes the bxCAN. In case the REC is over the limit, it is easily recovered by configuring the bxCAN in silent mode, assuming there is traffic on the CAN. However, if the TEC is over the limit, the bxCAN won't be able to transmit an other frame as the error interrupt will be instantly triggered once enabled -> there we are in a deadlock.
I tried decrementing the TEC by transmitting frames in silent loopback mode but successful transmissions do not affect the TEC in this mode it seems.
I suppose the question is not specific to this peripheral but valid for other CAN implementations.
Any suggestions are welcome.
I have implemented a work-around that seems to work fine, with the following requirements:
1.) whenever the CAN error ISR is triggered, it disconnects the node from the bus (the transceiver is powered off)
2.) not all interrupt sources are enabled, only the ones that are of higher severity than the last error state (e.g. in PASSIVE state the WARNING and PASSIVE interrupts are disabled and the BUSOFF interrupt is enabled)
3.) the last error state and thus the interrupt sources are updated whenever a.) an error ISR is triggered or b.) polling the CAN peripheral with a high frequency shows change in the error state
4.) whenever attempting a connection to the bus the REC must heal in listen-only mode first. For this, traffic is required on the bus.
With these requirements implemented the node is able to fail silently but recover to normal operation.
Is there any GPIO interrupt available for STM32F103ZE?
I went through the datasheet but didn't find anything related to that.
I am new to this processor but recently used TI's MSP430.
In MSP430 we can configure interrupts using some GPIO registers.
Can anybody tell me how can I do that?
Yes.
Please refer to the datasheet:
Section 8.1.3 states:
External interrupt/wakeup lines
All ports have external interrupt
capability. To use external interrupt lines, the port must be
configured in input mode. For more information on external interrupts,
refer to:
Section 9.2: External interrupt/event controller (EXTI) on page 174 and
Section 9.2.3: Wakeup event management on page 175.
If you check out section 9.2.5 you'll find that you have to set up the external interrupt peripheral (EXTI) in order to map the pins you want to observe into the correct interrupt.
Re-read sections 8 and 9 of the data sheet, and make certain you understand how each EXTI register needs to be setup to listen on the correct GPIO lines, and to trigger on the correct type of transition.
When entering an inteerupt handler, we first "disable interrupts" on that cpu(using something like the cli instruction on x86). During the time that interrupts are disabled, assume say the user pressed the letter 'a' on the keyboard that would usually cause an interrupt. But since interrupts are disabled, does that mean that:
the interrupt handler for 'a' would never be invoked, since interrupts are disabled in the critical section or
the interrupt will be handled by the os but delayed, until interrupts are enabled again.
Specifically, will the user need to press 'a' again, if the first time he pressed 'a' was at a time when interrupts were disabled ?
Often, one interrupt is "queued" by hardware.
[An interrupt is often just a logic gate that can stick on; once it's on, it stays on for a while.]
If the user hit 'a' once only during the interval when interrupts were disabled, it would register as an interrupt when they were re-enabled.
If the user somehow managed to hit 'a' twice during the interval when interrupts were disabled, one would register as an interrupt when they where enabled. Whether it was the first or the second depends on the exact logic gate configuration.
The answer is that it depends on whether you were already handling a keyboard interrupt.
Most interrupt service routines (ISR) have code at the termination of them which informs the hardware that it has been "serviced." In the case of the keyboard controller, commands are written to it acknowledging the received bytes. It is at the time of acknowledgement that the keyboard controller hardware stops using electricity to signal an interrupt condition.
If you are handling a non-keyboard interrupt, let's say the fire alarm interrupt, then the keyboard hardware which electrically asserts the interrupt will trigger as the key is pressed. The electrical signal is ignored until the CPU has interrupts enabled again. At the end of servicing the fire alarm interrupt, the fire alarm ISR acknowledges whatever data and re-enables interrupts on the CPU. Immediately, the CPU enters an interrupt because the keyboard controller is still electrically signalling an interrupt condition.
If you are handling a keyboard interrupt, and the user quickly types a second keystroke during the execution of your keyboard ISR, then there is a chance of missing the data from the second keystroke, or of receiving it later if at all. In particular, if the ISR resets the keyboard controller through an acknowledge, but the ISR has not actually received all the available bytes out of the keyboard controller, then that is a problem.
Often, an ISR will first handle the interrupt which triggered its activation, then after acknowledging the interrupt, poll the device to see if it has received more data since the first interrupt. If so, generate a software interrupt to re-enter the ISR and service the device.
The simple answer is that an interrupt automatically disables further interrupts. Interrupts should and are disabled for the shortest time only. The first instruction in the original AT BIOS keyboard ISR was STI to enable interrupts.
The happy answer is that the PIC prioritizes the hardware interrupts and even with interrupts enabled only the timer interrupt IRQ0 can interrupt the keyboard ISR. Of course a NMI can occur either way but happily this never occurs on a current PC.
It would be physically impossible for a user to press "a" twice during the normal processing of an interrupt. It would be terribly unlikely even if he pressed two keys at a time, but the hardware should hold at least one key until the CPU is ready to get it.
On PCs--this is reaching WAY back to my PCXT days--the keyboard subsystem may hold in the area of 13 key presses for the CPU.
Disable interupt have diffrent proof.
1. Hardware fault
2.exceptions { for example: Divide by zero }
and ect.
when hardware fault occure, the os must operate blend.
when the Exception occure, os must mangae the system and switch another process to handle interupt.
Or for example : for I/O device.
if the interupt was not, the computer wasn't efficiency!
1) How can the processor recognize the device requesting the interrupt?
2) Given that different devices are likely to require different ISR, how can the processor obtain the starting address in each case?
3) Should a device be allowed to interrupt the processor while another interrupt is being serviced?
4) How should two or more simultaneous interrupt requests be handled?
1) How can the processor recognize the device requesting the interrupt?
The CPU has several interrupt lines, and if you need more devices than there are lines there's an "interrupt controller" chip (sometimes called a PIC) which will multiplex several devices and which the CPU can interrogate.
2) Given the different devices are likely to require different ISR How can the pressor obtain the starting address in each case?
That's difficult. It may be by convention (same type of device always on the same line); or it may be configured, e.g. in the BIOS setup.
3) Should a device be allowed to interrupt the processor while amother interrupt is being services?
When there's an interrupt, further interrupts are disabled. However the interrupt service routine (i.e. the device-specific code which the CPU is executing) may, if it's willing, reenable interrupts if it's willing to be interrupted.
4) How should two or more simultanement interrupt requests be handled?
Each interrupt has a priority: the higher-priority interrupt is handled first.
The concept of defining the priority among devices so as to know which one is to be serviced first in case of simultaneous requests is called priority interrupt system. This could be done with either software or hardware methods.
SOFTWARE METHOD – POLLING
In this method, all interrupts are serviced by branching to the same service program. This program then checks with each device if it is the one generating the interrupt. The order of checking is determined by the priority that has to be set. The device having the highest priority is checked first and then devices are checked in descending order of priority.
HARDWARE METHOD – DAISY CHAINING
The daisy-chaining method involves connecting all the devices that can request an interrupt in a serial manner. This configuration is governed by the priority of the devices. The device with the highest priority is placed first.