I want to add an interruption on error code 0x7 : Store/AMO access fault of RISCV.
I created a SoC with LiteX tools. But, i don't happen to add my interruption in the vector interruption in mtvec register. The communication UART works under interruption. So, when i add my interruption, i lose the ability to write printf in the communication UART. I think I'm overriding the UART interruption.
How can i solve my problem ?
Thank you,
In fact, I want to add an interruption on mcause register at the value 0x7 : Store/AMO access fault of RISCV. I tried to change the mode of mtvec register. without any success.
Related
We want our device (STM32-F446RE running FreeRTOS + Telit ME310G1 modem) to communicate to the AWS cloud. We are trying to follow the Cellular Interface Library Demo, in particular following this- diagram
We are using coreMQTT Agent, MbedTLS libraries, the amazon communication interface implementation for UART and amazon UART API implementation.
UART using 115200 baud rate.
Currently failing on the Cellular_Init function when trying to send the first AT command to the modem, specifically when calling the HAL_UART_TRANSMIT_IT function from the above comm interface send function. While debugging we see that the USART1_IRQHandler is called infinite times and nothing is sent through the UART communication.
We are using the default handler, do we need to implement it in any way?
void USART1_IRQHandler(void)
{
HAL_UART_IRQHandler(&huart1);
}
Any help will be appreciated.
Thanks in advance,
Guy
Sounds like the UART line from HW point of view are not in a good state (High).
Did you check and ensure that the Power On sequence is done correctly? (Power On telit pin shall be high).
I expect you have some logic to translate the 1.8v to 3.3v and vice versa.
Can you check by measuring the different voltage that everything is OK?
If you verified all the point above.
Do you perform a reset on the telit side before starting the AT communication?
This ensure that you don't leave the module into a data mode where no AT commande are possible
Yacine
I am working on a project using a Zynq (Picozed devboard). The application is run bare-metal, uses lwIP TCP in RAW mode and basically behaves like this:
Receive a batch of data via Ethernet, which is stored in RAM.
Process the batch of data.
Send back the processed data via Ethernet.
The problem is, I need to measure the execution time of the processing part. However, running lwIP in RAW mode forces me to call tcp_fasttmr() and tcp_slowtmr() every 250/500 ms, which makes accurate measurement pretty hard. Whenever I'm not calling the tcp_tmr() functions for some time, I start repeatedly receiving error messages via UART ("unable to alloc pbuf in recv_handler"). It seems this is called from some ISR related to error handling, but I cannot really find the exact location.
My question is, how do I suspend the network functionality so I don't need to call tcp_tmr() periodically? I tried closing the connection and disabling the interface (netif_set_down()) and disabling the timer interrupt, but it still seems to have no effect on my problem.
I don't know anything about that devboard or the microcontroller on it but you should have an ethernetif.c (lwIP port) file which should contain the processing of an Ethernet receive interrupt or similar. This should be calling the lwIP function netif->input with a packet to process.
Disabling the interface won't stop this behaviour, it will just stop the higher level processing of the packet. If you are only timing how long the execution time is for debugging, you could try disabling the Ethernet receive interrupt and stop calling tcp_tmr until you have processed the packets.
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.
I'm trying to implement simple echo for UART on stm32f4 discovery board (using freertos). As far as I understand it should be very easy.
First I call HAL_UART_Receive_IT(&huart3, &rx_char,1) in a task. And after receiving an interrupt USART3_IRQHandler should trigger. And then in HAL_UART_RxCpltCallback I'll do HAL_UART_Transmit(&huart3, &rx_char, 1, timeout) and maybe re-enable it with HAL_UART_Receive_IT. Did I get the idea right? Should it work?
But in my case it doesn't. I'm trying to send a char from the terminal, but USART3_IRQHandler is never triggered. Nothing happens.
The code was generated using Stm32CubeMX with Freertos, USART3, NVIC and with USART3 global interrupt enabled.
Also I call __HAL_UART_ENABLE_IT(&huart3, UART_IT_RXNE) in main function.
What is wrong? HAL_UART_Transmit works perfectly.
HAL isn't ideal library. You must check registers, if something went wrong.
Your problem is looking like non-working NVIC. Check it, and if it wasn't turning on use something like - NVIC_EnableIRQ(USART3_IRQn);
Or may be wasn't switch on RE register in CR1 in USART3.
Anyway, I'm repeating - check registers.
Early Cisco routers running IOS operating system enhanced their packet processing speed by doing packet switching within the interrupt handler instead in "regular" operating system process. Doing packet processing in interrupt handler ensured that context switching within operating system does not affect the packet processing. As I understand, interrupt handler is a piece of software in operating system meant for handling the interrupts. How to understand the concept of packet switching done within the interrupt handler?
use of interrupts is preferred when an event requires some immediate attention by the operating system, or a program which installed an interrupt service routine. This as opposed to polling, where software checks periodically whether a condition exists, which indicates that the event has occurred.
interrupt service routines aren't commonly meant to do a lot of work themselves. They are rather written to reach their end as quickly as possible, so that normal execution can resume. "normal execution" meaning, the location and state previous processing was interrupted when the interrupt occurred. reason is that it must be avoided that the same interrupt occurs again while its handler is still executed, or it may be ignored, or lead to incorrect results, or even worse, to software failure (crashes). So what an interrupt service routine usually does is, reading any data associated with that event and storing it in a queue, signalling that the queue experienced mutation, and setting things such that another interrupt may occur, then resume by restoring pre-interrupt context. the queued data, associated with that interrupt, can now be processed asynchronously, without risking that interrupts pile up.
The following is the procedure for executing interrupt-level switching:
Look up the memory structure to determine the next-hop address and outgoing interface.
Do an Open Systems Interconnection (OSI) Layer 2 rewrite, also called MAC rewrite, which means changing the encapsulation of the packet to comply with the outgoing interface.
Put the packet into the tx ring or output queue of the outgoing interface.
Update the appropriate memory structures (reset timers in caches, update counters, and so forth).
The interrupt which is raised when a packet is received from the network interface is called the "RX interrupt". This interrupt is dismissed only when all the above steps are executed. If any of the first three steps above cannot be performed, the packet is sent to the next switching layer. If the next switching layer is process switching, the packet is put into the input queue of the incoming interface for process switching and the interrupt is dismissed. Since interrupts cannot be interrupted by interrupts of the same level and all interfaces raise interrupts of the same level, no other packet can be handled until the current RX interrupt is dismissed.
Different interrupt switching paths can be organized in a hierarchy, from the one providing the fastest lookup to the one providing the slowest lookup. The last resort used for handling packets is always process switching. Not all interfaces and packet types are supported in every interrupt switching path. Generally, only those that require examination and changes limited to the packet header can be interrupt-switched. If the packet payload needs to be examined before forwarding, interrupt switching is not possible. More specific constraints may exist for some interrupt switching paths. Also, if the Layer 2 connection over the outgoing interface must be reliable (that is, it includes support for retransmission), the packet cannot be handled at interrupt level.
The following are examples of packets that cannot be interrupt-switched:
Traffic directed to the router (routing protocol traffic, Simple Network Management Protocol (SNMP), Telnet, Trivial File Transfer Protocol (TFTP), ping, and so on). Management traffic can be sourced and directed to the router. They have specific task-related processes.
OSI Layer 2 connection-oriented encapsulations (for example, X.25). Some tasks are too complex to be coded in the interrupt-switching path because there are too many instructions to run, or timers and windows are required. Some examples are features such as encryption, Local Area Transport (LAT) translation, and Data-Link Switching Plus (DLSW+).
More here: http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12809-tuning.html