The title is pretty much self explanatory. When I write to the Output Compare Register (OC8RS or OC8R), an interrupt on the External Interrupt INT4 pin is triggered. I'm using the Timer3 & OC8 modules for PWM. The INT4 pin is connected to a physical switch that when pressed, triggers an interrupt. But, when I update the OC8RS register for my PWM function, an interrupt is triggered from INT4... which doesn't make sense (again, since this pin is connected to a physical switch - nothing to do with PWM).
I'm guessing I'm not initializing, setting, or clearing something correctly, but I'm out of ideas. Does anyone else have any? Thanks!
I'm using a PIC24HJ256GP610A processor, along with the latest MPLAB v8 and C30, and an ICD3.
I found a solution. Instead of setting the tristate bit of INT4 to be an input (i.e., bit 15 of TRISA = 1), I set it to be an output (TRISAbit15=0). Now, this doesn't make sense because as I've already stated, I'm using a mechanical switch to send a pulse to the INT4 pin when pressed... i.e., an input signal to the MCU. I have the INT4 pin connected to a 10K pullup resistor for the switch to work.
So, setting the pin/tristate bit as an output no longer causes the INT4 interrupt to trigger. The signal looks noisier than it should, as if it's "fighting" with another signal, but it works fine now. Still confused as to how this could work with the pin set as an output when it's receiving an input...
Related
I'm trying to start a DMA transfer on my stm32f412, and I've got everything set up to the point where I'm setting the control registers on the DMA channels/streams for TX and RX. I am able to set the enable (Bit 0) on the TX, but not the RX.
The datasheet has 3 options for the bit being cleared by hardware: 1.) On a DMA end of transfer (stream ready to be configured) 2.) If a transfer error occurs on the AHB master buses 3.) When the FIFO threshold on memory AHB port is not compatible with the size of the burst.
I don't think it could be the first or the third, because the DMA transfer hasn't even started yet, and there isn't a burst configured, it's just a single transfer. I'm not quite certain what the second means, but there aren't transfer errors marked in the error registers.
Any avenues to look into would be appreciated
Edit: Ugh, I was looking at the wrong registers for to find the DMA_LISR and _HISR. There was a transfer error on my RX channel.
From the description of DMA_SxCR_EN bit in the reference manual:
Note: Before setting EN bit to '1' to start a new transfer, the event flags corresponding to the
stream in DMA_LISR or DMA_HISR register must be cleared.
In my experience, these event flags include not only the error flags, but also the regular event flags like Transfer Complete or Half Transfer. In some cases, I also ended up clearing FIFO error flag, although I can't remember the reason behind it.
This problem manifests itself as "DMA works only once". In your case, it doesn't work even once, so there can be other problems. Still, I think it's worth trying to clear all the status flags before enabling the stream.
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.
I have a SPI for MSP430 written. If I send WRSR(01h) or RDSR(05h) to M25P64 flash.
The response I get from the Flash SPI_MISO is FFh.
So my question is "Is the response I have obtained is it right?"
How do I come to an understanding that handshaking between my SPI and Flash is correct?
Thanks
AK
Is the response I have obtained is it right?
The response is wrong. 30 seconds on Google and in the datasheet will tell you that. Things to check (since you have not provided any information):
How do I come to an understanding that handshaking between my SPI and Flash is correct?
Is this a new piece of SPI code? If so have you checked with an oscilloscope to see what you send out (clock and MOSI) is what you expect and matches what the datasheet says the device expects? It's the definitive way to be sure.
Does your SPI code work with any other devices?
Are your IO pins configured correctly on the MSP430?
Have you got the SPI module configured correctly for phase and polarity?
Did you forget to assert the chip select line?
What about HOLD?
Did you remember to send a dummy byte after the RDSR command so that the device would send the status register value?
Do you see a response from the device on an oscilloscope? Does the MSP430 read that value or a different one?
You are sometimes better first of all trying to read the device ID rather than the status register for a new piece of code. The reason for that is the device ID will never change, whereas the status register might change (although that depends on the device).
I am working on a project which uses a PIC24FJ64GA002 mcu.
I am working on a bit-banged serial communication function that will use one wire to send data and then switch to receive mode to receive data on the same pin. A separate pin will be used for clocking which will always be controlled by a different board (always an input). I am wondering is there a way to configure the pin for open-collector operation that that it can be used as an input and and output or do I have to change the pin configuration every time i go from reading to writing?
You need to change the direction of the pin each time by using the TRIS register. If the pin is set up as an output, reading the PORT register will most likely only tell you what level you are driving the pin to (assuming there is a high impedance on the pin). If the pin is set for input, you won't be able to drive your desired output value.
Also, make sure that you read incoming data using the PORT register, but output the data using the LAT register. This ensures that you don't suffer any issues if your code (I assume you are programming in C here) gets converted into bset/bclr/btgl instructions which are Read-Modify-Write. If you are writing in assembler, the same rule applies but you know when you are using these R-M-W type instructions. If you want more reasoning on this, please ask.
So, to open up a serial port and successfully transmit data from the balance through the serial port, i need to make sure that the settings on the serialPort object match the actual settings of the balance.
Now, the question is how do i detect that the connection hasn't been established due to the settings being different? No exception is thrown by serialPort.Open to indicate that the connection has been established. Yes, the settings are valid, but if they don't match the device (balance) settings; I am in the dark as to why the weight off the balance is not being captured.
Any input here?
Without knowing any more information on the format of the data you expect from your balance, only general serial port settings mismatch detection techniques are applicable.
If the UART settings are significantly incorrect, you'll likely see a lot of framing errors: when the UART is expecting a 1 stop bit, it will in fact see a 0. You can detect this with the ErrorReceived event on the port.
private void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e)
{
if ((e.EventType & SerialError.Frame) == SerialError.Frame)
{
// your settings don't match, try something else
}
}
If things are close, but still incorrect, the .NET serial port object may not even give you an error (that is, until something catastrophic occurs).
My most common serial port communication failure occurs due to mismatched baud rates. If you have a message that you know you can get an 'echo' for, try that as part of a handshaking effort. Perhaps the device you're connecting to has a 'status' message. No harm will come from requesting it, and you will find out if communication is flowing correctly.
For software handshaking (xon xoff) There's very little you can do to detect whether or not it's configured right. The serial port object can do anything from ignore it completely to have thread exception errors, depending on the underlying serial port driver implementation. I've had serial port drivers that completely ignore xon/xoff, and pass the characters straight into the program - yikes!
For hardware handshaking, the basic echo strategy for baud rate may work, depending on how your device works. If you know that it will do hardware handshaking, you may be able to detect it and turn it on. If the device requires hardware handshaking and it's not on, you may get nothing, and vice versa.
Another setting that's more rarely used is the DTR pin - data terminal ready. Some serial devices require that this be asserted (ie, set to true) to indicate that it's time to start sending data. It's set to false by default; give toggling it a whirl.
Note that the serial port object is ... finicky. While not necessarily required, I would consider closing the port before you make any changes.
Edit:
Thanks to your comments, it looks like this is your device. It says the default settings should be:
1200 baud
Odd parity
1 stop bit
Hardware handshaking
It doesn't specify how many data bits, but the device says it supports 7 and 8. I'd try both of those. It also says it supports 600, 1200, 2400, 4800, 9600, and 19200 baud.
If you've turned on hardware handshaking, enabled DTR (different things) and cycled through all the different baud rates, there's a good chance that it's not your settings. It could be that the serial cable that's being used may be wired incorrectly for your device. Some serial cables are 'passthrough' cables, where the 1-9 pins on one side match exactly with the 1-9 pins on the other. Then, you have 'crossover' cables, where the "TX" and "RX" cables are switched (so that when one side transmits, the other side receives, a very handy cable.)
Consider looking at the command table in the back of the manual there; there's a "print software version" command you could issue to get some type of echo back.
Serial ports use a very, very old communications technology that use a very, very old protocol called RS-232. This is pretty much as simple as it gets... the two end points have synchronized clocks and they test the line voltage every clock cycle to see if it is high or low (with high meaning 0 and low meaing 1, which is the opposite of most conventions... again an artifact of the protocol's age). The clock synchronization is accomplished through the use of stop bits, which are really just rest time in between bytes. There are also a few other things thrown into the more advanced uses of the protocol such as parity bits, XON/XOFF, etc, but those all ride on top of this very basic communication layer. Detecting a mismatch of the clocks on each end of the serial line is going to be nearly impossible -- you'll just get incorrect data on the recieving end. The protocol itself has no way built in to identify this situation. I am unaware of any serial driver that is smart enough to notice the input data being clocked an an inappropriate frequency. If you're using one of the error detection schemes such as parity bits, probabilistically every byte will be declared an error. In short, the best you can do is check the incoming data for errors (parity errors should be detected by your driver/software layer, whereas errors in the data received by your app from that layer will need to be checked by your program -- the latter can be assisted by the use of checksums).