# PIC32MZ UART RX crashes prvIdleTask **URL:** \ **Category:** Kernel\ **Created:** [March 28, 2017, 4:45pm UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506 "2017-03-28T16:45:06Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [March 28, 2017, 4:45pm UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/1 "2017-03-28T16:45:06Z")
**[arhancock](https://sourceforge.net/u/arhancock/)** wrote on [Tuesday, March 28, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#f756): I am porting our application form a custom PIC32MX board to a new custom PIC32MZ board. I am using Microchip’s Harmony 2.01b and FreeRTOS 9.x. I have two uarts configured in the project (UART 1 and 3). Both are transmitting okay. When I receive a character form UART 3, I get a general exception at an address that is in the middle of prvIdleTask. Being failry new to Harmony and FreeRTOS, I am at a loss at to how to debug this. I have tried increasing various stack sizes - no difference, and different Harmony usart models (Byte mode and Buffer queue mode) - not difference. Any ideas? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [March 28, 2017, 6:30pm UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/2 "2017-03-28T18:30:18Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, March 28, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#f756/61ca): Is it the case that your application code runs ok on the old board, but the exact same code does not run on the new board? If so, then the first question would be what is different about the boards? Are the PIC32 devices the same on both? If you think there is a stack overflow then the easiest thing to do is ensure stack overflow detection is turned on: [http://www.freertos.org/Stacks-and-stack-overflow-checking.html](http://www.freertos.org/Stacks-and-stack-overflow-checking.html) ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [March 30, 2017, 5:31pm UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/3 "2017-03-30T17:31:41Z")
**[arhancock](https://sourceforge.net/u/arhancock/)** wrote on [Thursday, March 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#9e09): The boards are significantly different, starting with the PIC. The old one is PIC32MZ695F512L and the new one is PIC32MZ2048EFH144. I/O has been reorganized around the new PICs I/O ports. The serial ports remain the same. The application is normally flashed with a custom USB based boot loader, residing in the lower part of program flash space. A linker script is used in the application build to move the application up 256K. If the application is build with the default linker script and flashed with a programmer, rather than with the boot loader, the serial RX works correctly. Analyzing the load maps between the two versions has not revealed anything helpful. Is there anything in FreeRTOS that needs to be adjusted for vector tables that have moved? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [March 31, 2017, 12:03am UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/4 "2017-03-31T00:03:25Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, March 31, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#9e09/d605): Not sure specifically for the PIC32 without cracking out the MIPS manuals to remind myself, but often devices require a register to be set to to the base address of the vector table. If the vector table is moved then the bootloader should setup the required registers before calling the application code. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [March 31, 2017, 1:21am UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/5 "2017-03-31T01:21:55Z")
**[arhancock](https://sourceforge.net/u/arhancock/)** wrote on [Friday, March 31, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#1010): The boot loader jumps to a copy of the reset code in the application - effectively rebooting the PIC at the application’s location. Again, many of the inerrupts are working, its just that UART TX event that trashes the system - event before the ISR get called. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [March 31, 2017, 2:32pm UTC](https://forums.freertos.org/t/pic32mz-uart-rx-crashes-prvidletask/6506/6 "2017-03-31T14:32:10Z")
**[arhancock](https://sourceforge.net/u/arhancock/)** wrote on [Friday, March 31, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/cc5d9a10/#6aff): I found that if I move the ebase\_addr in the linker script to place the IVT 64K above reset (rather than the 4K I had it at), the error goes away.