My setup is:
LPC1225FBD48/321
ext crystal: 16MHZ
PLL: MSEL=6, PSEL=2
UART0: CLKDIV=250 DL=1 DIVADDVAL=1 MULVAL=4
PLL gives mainclk=96MHz ; PCLK for UART is: 96MHz/250=384kHz ; Bit rate: 384kHz/(16x1x1.25)=19200
And it works, but only when LPC transmits. When LPC receives a character, it reports 2 characters received and sometimes framing error. Similar problem for other bit rates. At lower rates, like 2400, LPC reports single character received and sometimes framing error, but received character is not the same as I sent. It looks like Tx and Rx are using different clocks.
The UART works well when using bootloader with Flash Magic.
Has anyone encountered such a problem?
I finally found a solution. After setting CLKDIV = 50 and DL = 5, the UART became fully functional. While the documentation did not prohibit the previous set of parameters and both sets should give the same result, only the latter allows two-way communication.
I'm brand new to i2c and have an idea of what's required to read from a slave device using a master, however I am struggling to successfully code my pseudocode.
I'm wanting to read the local temperature sensor on the TI TMP468 using the TMS50ls1227PGE's i2c pins. I've enabled the i2c driver, pinmux, and enabled all of the i2c interrupts in HalCoGen. For reference, all non-standard functions are defined in TI's i2c.c file.
In CCS, I've typed the following code within a FreeRTOS task (I did i2cInit() in main):
i2cSetMode(i2cREG1, I2C_MASTER);
/* Set direction to receiver */
i2cSetDirection(i2cREG1, I2C_TRANSMITTER);
i2cSetStart(i2cREG1); //start bit
i2cSetSlaveAdd(i2cREG1, 0b1001000); //address of temp sensor
while(i2cIsTxReady(i2cREG1)){}; //wait until flag is clear
i2cSendByte(i2cREG1, 0b00000000); //register to read from
i2cSetStart(i2cREG1);
i2cSendByte(i2cREG1, 0b10010001); //read from sensor
i2cSetDirection(i2cREG1, I2C_RECEIVER);
while(i2cIsRxReady(i2cREG1)){};
data = i2cReceiveByte(i2cREG1); //read data
i2cSetStop(i2cREG1); //stop bit
I'm not seeing any activity in my data variable and when I debug my code is always stuck inside of void i2cInterrupt() at:
uint32 vec = (i2cREG1->IVR & 0x00000007U);
I'm not really sure where to go from here, any ideas or obvious mistakes?
Thanks!
I would recommend first trying to read from a register with non-changing contents: in the case of tmp468, that would be address FE, which contains Manufacturer's ID of 0x5449. That will allow you to "wring out" your I2C code.
(By the way, you may also want to ask this question in the http://e2e.ti.com/support/microcontrollers/hercules/ forum.)
I am working on a project where I'm trying to implement I2C master-slave communication so as to read some data from a magnetic sensor. That's all OK and I have written the code. However, I am not quite sure about the slave address needed for the communication to actually happen. The board I'm using can hold STM32 ARM® Cortex™-M3 and Cortex™-M4 MCU's. I don't know if it matters, but the MCU I'm using is STM32F107VCT6.
The part of the code where I need to enter the address is in the following function marked as "SLAVE_ADDRESS_GOES_HERE":
uint8_t Magnet_readReg(const uint8_t regAdd)
{
uint8_t pom[1] = {0};
pom[0] = regAdd;
I2C1_Start();
I2C1_Write(SLAVE_ADDRESS_GOES_HERE, pom, 1, END_MODE_RESTART);
I2C1_Read(SLAVE_ADDRESS_GOES_HERE, pom, 1, END_MODE_STOP);
return pom[0];
}
The results should be some numbers which tell me how strong the magnetic field is. It has three different values as an output because it calculates a value for each of the three axes (yes, it's the correct plural of the word axis), so it can could be used as a compass for example.
Now the trick is that I don't get any results because I don't know the actual address of the sensor. Therefore, I will share the datasheet of the sensor I'm using. I am not sure if i'm reading it correctly.
Here is the datasheet:
https://www.memsic.com/userfiles/files/Datasheets/Magnetic-Sensors-Datasheets/MMC3416xPJ_Rev_C_2013_10_30.pdf
Solved.
As it turns out, there was something wrong with the board itself. Therefore, a connection couldn't be established. And the address is 60H for writing and 61H for reading. 30H is the address, but when you add a zero or a one in the LSB position you get 60H or 61H.
The I2C address of your sensor is described on page 4 of the datasheet you provided. You must read the marking on your device package, then use the table from "Number" to "Part number" in the datasheet to determine your exact part. Finally, use the table under the "Ordering Guide" to find the factory-programmed I2C slave address of your device.
Given that you later specified that your 7-bit I2C slave address is 0x30, then you must have part number MMC34160PJ, which should be marked:
0 •
XX
I am using PIC32MZ2048ECH144. I have two switches connected to RH8(pin Number 81) and RH9(pin Number 82). I do not see any option in MHC to set interrupt at pin level, therefore I get the ISR generated for the port-H. I need the ISRs for each pin to be invoked separately.
Hence, in "system_init.c", in "SYS_Initialize" function I added the following lines,
PLIB_PORTS_PinChangeNoticePerPortEnable(PORTS_ID_0, PORT_CHANNEL_H, PORTS_BIT_POS_8);
PLIB_PORTS_PinChangeNoticePerPortEnable(PORTS_ID_0, PORT_CHANNEL_H, PORTS_BIT_POS_9);
The ISR generated by MHC in "system_interrupt.c":
void __ISR(_CHANGE_NOTICE_H_VECTOR, ipl3AUTO) _IntHandlerChangeNotification_PortH1(void)
{
PLIB_INT_SourceFlagClear(INT_ID_0,INT_SOURCE_CHANGE_NOTICE_H);
APP_SwitchChangeNoticed();
}
I replaced the above ISR macro with the below lines:
void __ISR(_ADC1_DATA22_VECTOR, ipl3AUTO) _IntHandlerChangeNotification_PortH1(void)
{
PLIB_INT_SourceFlagClear(INT_ID_0, INT_SOURCE_CHANGE_NOTICE);
APP_SwitchChangeNoticed();
}
void __ISR(_ADC1_DATA23_VECTOR, ipl3AUTO) _IntHandlerChangeNotification_PortH(void)
{
PLIB_INT_SourceFlagClear(INT_ID_0,INT_SOURCE_CHANGE_NOTICE_H);
test1();
}
This did not work out. I referred the link http://microchip.wikidot.com/faq:78. I feel I am wrong in choosing the vector numbers for the ISR macros from "/pic32mx/include/proc/p32mz2048ech144.h". (I used _ADC1_DATA22_VECTOR and _ADC1_DATA23_VECTOR thinking that the values against them 81 and 82 are pin numbers, which again did not work.) Any help or hints on how to set pin level interrupts(2 pins on the same port) would be really great! Kindly apologize for any mistakes in my post.
Thanks in advance.
The short answer is that what you are asking for cant be achieved directly with two separate ISRs. There is only one change notification ISR vector available for the whole H port. You would normally achieve what you are looking for with an added software check to determine which of your two pins is in a different state. Another method is to simple move your signal to another port (if your board is not finalized).
The name you give the function has no bearing on what the ISR will react to. The real magic comes in the __ISR macro arguments.
For example:
void __ISR(_CHANGE_NOTICE_H_VECTOR, ipl3AUTO) _IntHandler1234()
Notice the _CHANGE_NOTICE_H_VECTOR; it signifies that this interrupt service routine will be called when the change notification interrupt happens on port H.
The Problem: I send one value into a UART and nulls emerge on the other UART.
--- Details ---
These are both PIC processors (PIC24 and PIC32)
They are both hard wired onto a printed circuit board.
They are communicating, each via one of the UART modules which reside within them.
They are (ostensibly; according to docs) both configured for 115200 bps, 8-N-1
No handshaking, no CTS enabled, no RTS enabled; I'm just putting bytes on the wire and out they go.
(These are short little 4-byte commands and responses which fits pretty neatly)
The PIC32 is going 80 MHz.
The PIC24 has F[cy] = 14745600
i.e., it is going 14.7456 MHz
The PIC24 sends four bytes (a specific command sequence)
When I set a breakpoint at the Interrupt Service Routine for the UART, The PIC32 shows nulls, then I am seeing repeated hits on the (PIC32 code) breakpoint after the first four, and I continue to see nulls (which makes sense since the PIC24 is not sending anything)
i.e., the UART appears to be repeatedly generating interrupts when there is no reason
I did not write the code on the PIC32 side, and I am learning daily how it works.
Then I let the code just run, and I inevitably wind up on a line that says
52570 1D01_335C 9D01_335C _general_execption_handler sdbbp 0x0
When I get there,
The cause register holds 0080181C
The EPC register holds 9D00F228
The SP register holds 9F8FFFA0
This happened like clockwork, so I got suspicious of the __ISR that would not stop. MpLab showed me this...
432:
433: //*********************************************************//
434: void __ISR(_UART1_VECTOR, ipl5) IntUart1Handler(void) //MCU communication port
435: {
9D00F204 415DE800 rdpgpr sp,sp
9D00F208 401A7000 mfc0 k0,EPC
9D00F20C 401B6000 mfc0 k1,Status
9D00F210 27BDFF88 addiu sp,sp,-120
9D00F214 AFBA0074 sw k0,116(sp)
9D00F218 AFBB0070 sw k1,112(sp)
9D00F21C 7C1B7844 ins k1,zero,1,15
9D00F220 377B1400 ori k1,k1,0x1400
9D00F224 409B6000 mtc0 k1,Status
9D00F228 AFBF0064 sw ra,100(sp) ;<<<-------EPC register always points here
9D00F22C AFBE0060 sw s8,96(sp)
9D00F230 AFB9005C sw t9,92(sp)
9D00F234 AFB80058 sw t8,88(sp)
9D00F238 AFAF0054 sw t7,84(sp)
9D00F23C AFAE0050 sw t6,80(sp)
9D00F240 AFAD004C sw t5,76(sp)
9D00F244 AFAC0048 sw t4,72(sp)
9D00F248 AFAB0044 sw t3,68(sp)
9D00F24C AFAA0040 sw t2,64(sp)
9D00F250 AFA9003C sw t1,60(sp)
9D00F254 AFA80038 sw t0,56(sp)
9D00F258 AFA70034 sw a3,52(sp)
9D00F25C AFA60030 sw a2,48(sp)
9D00F260 AFA5002C sw a1,44(sp)
9D00F264 AFA40028 sw a0,40(sp)
9D00F268 AFA30024 sw v1,36(sp)
9D00F26C AFA20020 sw v0,32(sp)
9D00F270 AFA1001C sw at,28(sp)
9D00F274 00001012 mflo v0
9D00F278 AFA2006C sw v0,108(sp)
9D00F27C 00001810 mfhi v1
9D00F280 AFA30068 sw v1,104(sp)
9D00F284 03A0F021 addu s8,sp,zero
I look a little more closely at the numbers, and I see that at that time, if we add 100 (0x64) to FFA0 (the bottom 16 bits of the SP) we get 0x10004, which I am guessing is 4 too much.
PIC Manual DS61143E-page 50 says that that nomenclature means, SW Store Word Mem[Rs+offset> = Rt and other experts have told me that the cause register is telling me that the EXCCODE bits are 7 which is the code for a bus exception on load or store.
Or, I'm totally guessing here (would love to get some experts' knowledge on this) something is not clearing something and I'm encountering infinite recursion on an int handler.
All of this is starting to make sense.
THE QUESTION
Could someone please suggest the most common reasons for an int like this to be repeatedly hitting me ?
Does anyone see any common relationship between the bogus nuls coming from the UART which could somehow be connected with this endlessly generated int ? Am I even on the right track ?
In your answer, please tell me how to acknowledge the Int from the UART. I know how I do that in the PIC24 (I wrote that code totally, in ASM) but I don't know how this is done in in C on the PIC32. Assembly will be fine. I'll inline it. I'm working with code I didn't write here, and I thank you for your answers
What is the most common reason that the UART (#1, in this case) would be repeatedly generating interrupts ?
The most common reason an interrupt subroutine is called over and over is that the interrupt request is never acknowledged in the routine.
Are you sure you clear the corresponding IRQ bit?
To ease UART debugging you should first connect the UART to a PC and make sure your target can communicate both ways with the PC. With two targets at the same time, you can't determine on which one the problem is apart from inspecting signals with a scope.
On many devices an interrupt must be explicitly cleared to prevent the ISR from simply re-entering when complete.
In most cases a UART will have status bits that indicate the source of the interrupt, knowing that might tell you something, but not telling us makes it difficult to help you. You can inspect the UART registers directly in the debugger, however in some devices the act of reading a bit may in fact clear a bit, and that is true in the debugger too, so be aware of that possibility (check the data sheet/user manual).
Some UARTS require their transmitter to be explicitly switched off to stop transmitting nulls, while others are triggered automatically when data is placed in the tx register and stop after the necessary number of bits are shifted out. Again check the data sheet/manual for the part. If the PIC32 code is known to be working, then since this possible error would be with the PIC24 code, it seems to fit. You can check this simply by using an oscilloscope on the Tx line from the PIC24, if it is transmitting, you will see at least start/stop bit transitions (framing). If there is nothing, then the problem is probably at the PIC32 end.
While you have the scope out, you can check that the bit timing is correct and that you are actually transmitting at 115200. It is easy to get the clocking wrong, and that should be your first check. If the baud rate is incorrect, the PIC32 will likely generate framing error interrupts, which if not handled may persist indefinitely.
Another possibility is that after transmission the PIC24 leaves the line in the "break" state, and that the PIC32 UART is generating "line-break" interrupts. That is why it is important to look at the UART status registers to determine the interrupt cause.
As you can see, there are many possibilities; I think I have covered the most likely ones, but more methodical debugging effort and information gathering on your part is required. I hope I have guided you in this too.
There were the three root causes which were in place...
The interrupt priority level was set at value 6 in the initialization code for UART1
The first line of the interrupt service routine was coded with an interrupt priority level of 5
The first three bytes of UART data were disappearing from the data stream (this is still unsolved)
Here's the not-so-obvious way they were causing the problem
First three bytes never appeared
Fourth byte did appear
Interrupt hit (as level 6) and invoked __ISR routine
__ISR was acting as ipl5 agent
First instruction executed (possibly more, I couldn't debug that accurately)
As soon as the first instruction finished, the "higher" priority 6 interrupt immediately kicked in
This resulted in the same interrupt again
The process repeated itself infinitely.
In short order, Stack Overflow resulted
The Fix
Make sure these two lines of code agree with each other...
The IPL line in the init code, wrong way then the right way
//IPC6bits.U1IP=6; //// Wrong !!! Uart 1 IPL should not be 6 !!!
IPC6bits.U1IP=5; //// Uart 1 IPL = 5 Correct way; matches __ISR
Interrupt Service Routine
void __ISR(_UART1_VECTOR, ipl5) IntUart1Handler(void) //// Operating as IPL 5
:
:
:
:
Poor design decision. If both are on same board SPI would have been more feasible and a lot faster.