CHAT2: PROGRAM UDB4 WITH PICKIT2 (May 6, 2013):
Mechrobotics:
Hi all,
Is it possible to program the UDB4 with pickit2.
Morli:
Yes, it should work
regards
Morli
William Premerlani:
Yes, it is possible to program the UDB4 with pickit2, but the steps are a little different:
1. build the firmware using MPLAB.
2. export the hex file.
3. run a separate PICkit2 programming tool provided by Microchip.
Here is the tool (tool available on - UAVDevBoard UDB4 with PICKIT2)
You will also need a device update file (available on - UAVDevBoard UDB4 with PICKIT2)
Best regards,
Bill
Mechrobotics:
Thanks bill,
Got it its working now thanks to provide update file.
Regards
guru
CHAT1: GPS RESETTING IN AUTOPILOT MODE (May 3, 2013):
Manya:
Post 8. Simulation to confirm the U.A.V. telemetry
The problem of resetting G.P.S. is still persisting. We are trying to figure whats wrong. With the whole telemetry setup our micro-controller resets itself when we switch to the autopilot mode. We thought that this was happening as individual components on the board (like the transmitter) may also be deriving voltage from our supply and also since data had to be simultaneously sent to two programs (HK G.C.S. & X-Plane Demo 9), this process may also be consuming our voltage. Therefore, we built a separate power supply for our transmitter on the testing kit. We used a 9 volt DC adapter and 7805 component with 100 micro-farad capacitor. But we are surprised that the problem is still there.
We changed the serial data transmission mode also in the options.h file of the Matrix-Pilot code (from SERIAL_NONE, SERIAL_ARDUSTATION, SERIAL_UDB to SERIAL_UDB_EXTRA) and we also changed the UDB Board (tried UDB3_BOARD and RED_BOARD), but no improvement. Maybe there is something wrong with the program. We are still checking it out.
Please if somebody can figure this out then help.
MechRobotics:
Well here i summarize of the problem, Its the own designed DSPIC30F4011 board (UDB3), which is designed for Simulation in Xplane specifically . We are using the latest code version. It simulates all the modes well without telemetry(with Serial_None in option.h). But if we enable any telemetry in option.h, microcontroller works well in manual and stabilised mode and in autopilot mode it gets reset. Please suggest what could be the problem.
Regards
Vikram
Ansuz:
G'day Vikram,
I'd suggest that if the board is resetting, then one of the trap handlers is probably calling the reset instruction. The default code only reports this in the telemetry, so you would want to setup some other way of reporting it. There is code in the MatrixPilot_AUAV3 branch to do this, in the mcu.c module. Firstly i'd suggest configuring your otherwise unused telemetry channel to report debug output.
Given that you say you are using your own board, do you have a genuine UDB3 to compare results with. This would be useful to eliminate the possibility that it is something inherent in your board design, which if is the case, none of us will be able to help you with.
Otherwise, you'll need to provide a lot more detail before I could add much more to help at this point.
Best wishes, Robert.
Pete:
Vikram,
Also, if you switch on the telemetry for SERIAL_UDB_EXTRA, it will report the reason / code for the reboot (including power problem, and types of traps), as well as the program location at which the reboot occured.
The reboot reason is printed out as soon as the telemetry starts and is in the following telemetry lines ...
please see the green highlighted section in the first line. You will need to study the PIC30F4011 manual to decode RCON and the Trap Flags. Trap Source is the location in memory that was used for the instruction that generated the trap. RCON will tell you about any brown outs (low power problems).
F14:WIND_EST=1:GPS_TYPE=2:DR=1:BOARD_TYPE=5:AIRFRAME=0:RCON=0x3:TRAP_FLAGS=0x0:TRAP_SOURCE=0x0:ALARMS=0:CLOCK=3:FP=2:
F15:IDA=Alpha Axion 139 3X:IDB=AA-PDH-UK:
F16:IDC=Pete Hollands:IDD=http://www.diydrones.com/profile/PeterHollands:
F4:R_STAB_A=1:R_STAB_RD=0:P_STAB=1:Y_STAB_R=0:Y_STAB_A=0:AIL_NAV=1:RUD_NAV=1:AH_STAB=0:AH_WP=3:RACE=0:
Best wishes, Pete
William Premerlani:
Vikram,
Also, in the SERIAL_UDB_EXTRA telemetry, the CPU loading is reported:
F2:T0:S100:N0:E0:A0:W0:a16384:b12:c-36:d-10:e16384:f12:g36:h-12:i16384:c0:s0:cpu8:bmv0:as0:wvx0:wvy0:wvz0:ma0:mb0:mc0:svs0:hd0:p1i2916:p2i2980:p3i2057:p4i2686:p1o2917:p2o2980:p3o2057:imx0:imy0:imz0:lex0:ley0:lez0:fgs800:ofc0:tx0:ty0:tz0:G0,0,0:
In the line above, the cpu load is reported as 8 percent.
In your case, I think your board is resetting because of high CPU load. There are a couple of suspects:
1. Perhaps you are using a lower frequency crystal.
2. There is a known problem in one of the versions of Microchip's library print function. If you are using either an older version of
Microchip's compiler and MPLAB, or an older version of MatrixPilot, this could be the reason.
Best regards,
Bill
Manya Sharma:
Dear Bill,
We are using 16 MHz crystal with DSPIC30F4011 and MPLab Version is 8.36 with the latest C30 compiler (Ver.3_31). We configured it on UDB_EXTRA telemetry and captured it which I am attaching with this post. Please find options.h and capture.txt attached with this post. I think I am getting 64% CPU usage.
Ansuz:
64% seems way to high. Do you have use-legacy-clib enabled/defined. I think that gets around the printf bug Bill is referring to.
Manya Sharma:
Dear Bill,
This is the second test, this time we had MPLab Version 8.9 and C30 compiler version (3_31). And again its getting reset. I have attached the capture file for further reference.
Ansuz:
Hi Manya,
From your two capture files, here are the elements of interest:
RCON=0x20C3:TRAP_FLAGS=0x2:TRAP_SOURCE=0x6CBE
RCON=0x2043:TRAP_FLAGS=0x2:TRAP_SOURCE=0x466C
Look up RCON in the datasheets. Trap flag 2 is a stack exception. Trap source is the address it occurred at. Use the view disassembly window to track down the location in code.
Manya Sharma:
robert
In my case legacy-libc is disabled.do i need to enable it?
Pete:
Here is a screenshot of my setup for legacy-libc. It is enabled.
Mechrobotics:
Hi all,
Is it possible to program the UDB4 with pickit2.
Morli:
Yes, it should work
regards
Morli
William Premerlani:
Yes, it is possible to program the UDB4 with pickit2, but the steps are a little different:
1. build the firmware using MPLAB.
2. export the hex file.
3. run a separate PICkit2 programming tool provided by Microchip.
Here is the tool (tool available on - UAVDevBoard UDB4 with PICKIT2)
You will also need a device update file (available on - UAVDevBoard UDB4 with PICKIT2)
Best regards,
Bill
Mechrobotics:
Thanks bill,
Got it its working now thanks to provide update file.
Regards
guru
CHAT1: GPS RESETTING IN AUTOPILOT MODE (May 3, 2013):
Manya:
Post 8. Simulation to confirm the U.A.V. telemetry
The problem of resetting G.P.S. is still persisting. We are trying to figure whats wrong. With the whole telemetry setup our micro-controller resets itself when we switch to the autopilot mode. We thought that this was happening as individual components on the board (like the transmitter) may also be deriving voltage from our supply and also since data had to be simultaneously sent to two programs (HK G.C.S. & X-Plane Demo 9), this process may also be consuming our voltage. Therefore, we built a separate power supply for our transmitter on the testing kit. We used a 9 volt DC adapter and 7805 component with 100 micro-farad capacitor. But we are surprised that the problem is still there.
We changed the serial data transmission mode also in the options.h file of the Matrix-Pilot code (from SERIAL_NONE, SERIAL_ARDUSTATION, SERIAL_UDB to SERIAL_UDB_EXTRA) and we also changed the UDB Board (tried UDB3_BOARD and RED_BOARD), but no improvement. Maybe there is something wrong with the program. We are still checking it out.
Please if somebody can figure this out then help.
MechRobotics:
Well here i summarize of the problem, Its the own designed DSPIC30F4011 board (UDB3), which is designed for Simulation in Xplane specifically . We are using the latest code version. It simulates all the modes well without telemetry(with Serial_None in option.h). But if we enable any telemetry in option.h, microcontroller works well in manual and stabilised mode and in autopilot mode it gets reset. Please suggest what could be the problem.
Regards
Vikram
Ansuz:
G'day Vikram,
I'd suggest that if the board is resetting, then one of the trap handlers is probably calling the reset instruction. The default code only reports this in the telemetry, so you would want to setup some other way of reporting it. There is code in the MatrixPilot_AUAV3 branch to do this, in the mcu.c module. Firstly i'd suggest configuring your otherwise unused telemetry channel to report debug output.
Given that you say you are using your own board, do you have a genuine UDB3 to compare results with. This would be useful to eliminate the possibility that it is something inherent in your board design, which if is the case, none of us will be able to help you with.
Otherwise, you'll need to provide a lot more detail before I could add much more to help at this point.
Best wishes, Robert.
Pete:
Vikram,
Also, if you switch on the telemetry for SERIAL_UDB_EXTRA, it will report the reason / code for the reboot (including power problem, and types of traps), as well as the program location at which the reboot occured.
The reboot reason is printed out as soon as the telemetry starts and is in the following telemetry lines ...
please see the green highlighted section in the first line. You will need to study the PIC30F4011 manual to decode RCON and the Trap Flags. Trap Source is the location in memory that was used for the instruction that generated the trap. RCON will tell you about any brown outs (low power problems).
F14:WIND_EST=1:GPS_TYPE=2:DR=1:BOARD_TYPE=5:AIRFRAME=0:RCON=0x3:TRAP_FLAGS=0x0:TRAP_SOURCE=0x0:ALARMS=0:CLOCK=3:FP=2:
F15:IDA=Alpha Axion 139 3X:IDB=AA-PDH-UK:
F16:IDC=Pete Hollands:IDD=http://www.diydrones.com/profile/PeterHollands:
F4:R_STAB_A=1:R_STAB_RD=0:P_STAB=1:Y_STAB_R=0:Y_STAB_A=0:AIL_NAV=1:RUD_NAV=1:AH_STAB=0:AH_WP=3:RACE=0:
Best wishes, Pete
William Premerlani:
Vikram,
Also, in the SERIAL_UDB_EXTRA telemetry, the CPU loading is reported:
F2:T0:S100:N0:E0:A0:W0:a16384:b12:c-36:d-10:e16384:f12:g36:h-12:i16384:c0:s0:cpu8:bmv0:as0:wvx0:wvy0:wvz0:ma0:mb0:mc0:svs0:hd0:p1i2916:p2i2980:p3i2057:p4i2686:p1o2917:p2o2980:p3o2057:imx0:imy0:imz0:lex0:ley0:lez0:fgs800:ofc0:tx0:ty0:tz0:G0,0,0:
In the line above, the cpu load is reported as 8 percent.
In your case, I think your board is resetting because of high CPU load. There are a couple of suspects:
1. Perhaps you are using a lower frequency crystal.
2. There is a known problem in one of the versions of Microchip's library print function. If you are using either an older version of
Microchip's compiler and MPLAB, or an older version of MatrixPilot, this could be the reason.
Best regards,
Bill
Manya Sharma:
Dear Bill,
We are using 16 MHz crystal with DSPIC30F4011 and MPLab Version is 8.36 with the latest C30 compiler (Ver.3_31). We configured it on UDB_EXTRA telemetry and captured it which I am attaching with this post. Please find options.h and capture.txt attached with this post. I think I am getting 64% CPU usage.
Ansuz:
64% seems way to high. Do you have use-legacy-clib enabled/defined. I think that gets around the printf bug Bill is referring to.
Manya Sharma:
Dear Bill,
This is the second test, this time we had MPLab Version 8.9 and C30 compiler version (3_31). And again its getting reset. I have attached the capture file for further reference.
Ansuz:
Hi Manya,
From your two capture files, here are the elements of interest:
RCON=0x20C3:TRAP_FLAGS=0x2:TRAP_SOURCE=0x6CBE
RCON=0x2043:TRAP_FLAGS=0x2:TRAP_SOURCE=0x466C
Look up RCON in the datasheets. Trap flag 2 is a stack exception. Trap source is the address it occurred at. Use the view disassembly window to track down the location in code.
Manya Sharma:
robert
In my case legacy-libc is disabled.do i need to enable it?
Pete:
Here is a screenshot of my setup for legacy-libc. It is enabled.
Best wishes, Pete
Manya Sharma:
Thanks Peter,Bill and Robert,
Problem is solved , i had enabled the legacy libc in my project file and yes now its working without reset and cpu usage is 8-10. Thanks for answering my questions . So the problem was legacy libc was disabled.
Thanks And Regards
Manya
Ansuz:
you're welcome, breathe deep - fly high (-:
Manya Sharma:
That is what actually I am doing. My cesna is flying high (in autopilot mode) in X Plane 9. :D
No comments:
Post a Comment