Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
21-01-2014, 03:17 PM,
#11
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Any idea why it exists at all instead of Mchp just continuing with the USB code they already had?

Is it the same code with some tweaks?

John
Reply
21-01-2014, 06:05 PM, (This post was last modified: 21-01-2014, 06:36 PM by fcapozzi.)
#12
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
.. may be a marketing issue ... to appeal the potential customer with easy developing tools in order to gain position among other competitors (Atmel, Texas ... )

Apart the USB stack i am unable to test and debug for now i've conducted an experiment which lead me to think that there is some conflict in the memory areas changed by the bootloader.

A first i written a very simple main.c file with harmony port lib that is the simplest to use

Quote:#include <stdio.h>
#include <stdlib.h>
#include "peripheral/peripheral.h"
#include "peripheral/ports/plib_ports.h"

/*
*
*/
int main(int argc, char** argv) {

PLIB_PORTS_DirectionOutputSet
(
PORTS_ID_0,
PORT_CHANNEL_A,
(PORTS_DATA_MASK)0x0001
);

PLIB_PORTS_Clear
( PORTS_ID_0,
PORT_CHANNEL_A,
(PORTS_DATA_MASK) 0x0001
);

PLIB_PORTS_PinOpenDrainDisable
(
PORTS_ID_0,
PORT_CHANNEL_A,
PORTS_BIT_POS_0
);

PLIB_PORTS_PinSet(PORTS_ID_0,PORT_CHANNEL_A,PORTS_BIT_POS_0);

while(1);

return (EXIT_SUCCESS);
}


In order to compile it with harmony library we might to add in the MPLAB project library section the specific processor file "PI32MX250F128B_peripheral.a" and in the gcc option put a reference to the include files. Using the optimization level 1 the program compile and work
The led come up.
If i compile the program with optimization level 1 the generated code is 1080 bytes
and the program run correctly

if i compile the program with optimization level 0 the generated code is 109208 bytes.
when loading the code with pic32prog i see
Quote:Programmer for Microchip PIC32 microcontrollers, Version 1.91M
Copyright: © 2011-2013 Serge Vakulenko
Adapter: HID Bootloader
Program area: 1d003000-1d01ffff
Processor: Bootloader
Flash memory: 116 kbytes
Data: 109208 bytes
Erase: done
Program flash: ################################################### done............................................
Program boot: # done
Rate: 27227 bytes per second
as the loading process has been aborted in the middle (looking at the dots not processed) Actually looking at the information the bootloader reported the program area is between 1d003000 and 1d01ffff that are 118783 bytes in decimal that should be sufficient but something happen in the loading process.
If the program is short (optimization level 1) the ouput is different

Quote:Programmer for Microchip PIC32 microcontrollers, Version 1.91M
Copyright: © 2011-2013 Serge Vakulenko
Adapter: HID Bootloader
Program area: 1d003000-1d01ffff
Processor: Bootloader
Flash memory: 116 kbytes
Data: 1096 bytes
Erase: done
Program flash: ##### done
Program boot: # done
Rate: 6602 bytes per second
Now the code il fully loaded and the code work .. so the usb weird behaviour may be due to not complete loading of the code with strange results
Now the question is .. may be the pic32prog has problem ?? or is the bootloader that set some costrains in the program code he expect .. (program memory, data memory, heap ..)
Further investigation is needed.

Enjoy, Fabio.


(21-01-2014, 02:13 PM)fcapozzi Wrote: ...oohhh ... lerning USB with a troubled early beta library is a pretty weird thing to do .. since i dont know if i'm wrong or is the library that is fault ... however i've done some experiments that exploit some other strange things .. i will came later with details

:-) Fabio

(21-01-2014, 12:22 AM)agolac Wrote: Yeep. This harmony is deeply troubled library in early beta stage. I fixed few errors and another dozen emerges, at least for 440MX256H. Bunch of stuff is missing from its header files which throw errors. I'm done with it until more stable release comes out. Good luck ;o)
Reply
21-01-2014, 08:27 PM, (This post was last modified: 21-01-2014, 08:53 PM by agolac.)
#13
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
(21-01-2014, 03:17 PM)pingotg Wrote: Any idea why it exists at all instead of Mchp just continuing with the USB code they already had?

Is it the same code with some tweaks?

John

It is new code and they added few more layers of complexity. It seems they are going for "no brainer" mega library wich will hide all of the underlying hardware to programmer and offer ultimate code portabilty among different processors. I must say I didn't even know that this exists until Fabio brought it up. I saw only small note and link to harmony download area. This is probably because of its beta stage...

(21-01-2014, 06:05 PM)fcapozzi Wrote: Now the code il fully loaded and the code work .. so the usb weird behaviour may be due to not complete loading of the code with strange results
Now the question is .. may be the pic32prog has problem ?? or is the bootloader that set some costrains in the program code he expect .. (program memory, data memory, heap ..)
Further investigation is needed.

Enjoy, Fabio.

Maybe there is a way to download the flashed program from flash and do checksum comparing file to the original... By the way, aren't code optimizations crippled (forbidden) in MPLAB compiler? Really huge difference in code size phew... I will never understand why they did that. They are just annoying their customers forcing them to choose another vendor...
Dreaming in Code...
Reply
21-01-2014, 09:12 PM,
#14
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
... since xc32 is based upon gcc i've seen while surfing the net some istructions to rebuild the xc source code (that seem to be available) in such a way that the optimization is available only if xc is "free version" .. just reverting the condition... and the key check .... in this moment i'm not interested about, since i'm just testing the processor but should need space for a real application we should try ;-) this way ..

However i want to test uploading the program with the ubw32 used int Pinguino IDE .. but i don't know yet the syntax and paramter usage .....

(21-01-2014, 08:27 PM)agolac Wrote: [Maybe there is a way to download the flashed program from flash and do checksum comparing file to the original... By the way, aren't code optimizations crippled (forbidden) in MPLAB compiler? Really huge difference in code size phew... I will never understand why they did that. They are just annoying their customers forcing them to choose another vendor...
Reply
21-01-2014, 09:31 PM,
#15
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Thanks.

There's a link to somewhere (er, Dangerous Protoypes maybe) on how to use a non-crippled C32. But frankly you're right that it's just daft to annoy customers. It's so easy to use free full C / C++ compilers with all optimisations for ARM. Mchp seem ignorant that they have competition.

fcapozzi - make sure you have really recent pic32prog as I know some not so recent have a few problems. May not be the issue but worth trying.

John
Reply
21-01-2014, 09:48 PM,
#16
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I think one could probably ln -s and link pinguino compiler instead of xc32-gcc and with few tweeks make it work with MPLABX
Dreaming in Code...
Reply
22-01-2014, 01:20 AM,
#17
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I guess i found something interesting. If i compile TestCDC.X project (the one i attached as first message) without the modified elf32pic32mx.ld modified linker files needed to allow uploading through the bootloader the memory usage report generated by compiler is


Microchip PIC32 Memory-Usage Report

kseg0 Program-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.text 0x9d004a00 0x1184 4484 App's exec code
Driver 0x9d005b84 0xec8 3784
.text._vfprintf_cdnopsu 0x9d006a4c 0xad0 2768
.text 0x9d00751c 0x140c 5132 App's exec code
Driver 0x9d008928 0x458 1112
.text 0x9d008d80 0x868 2152 App's exec code
.rodata 0x9d0095e8 0x3cc 972 Read-only const
.dinit 0x9d0099b4 0x280 640
.text 0x9d009c34 0x6b8 1720 App's exec code
.text.fputc 0x9d00a2ec 0x15c 348
.text 0x9d00a448 0x278 632 App's exec code
.text._flsbuf 0x9d00a6c0 0x12c 300
.rodata 0x9d00a7ec 0x220 544 Read-only const
.text.general_exception 0x9d00aa0c 0xdc 220
.rodata 0x9d00aae8 0xd0 208 Read-only const
.text._mon_putc 0x9d00abb8 0xb4 180
.text 0x9d00ac6c 0x94 148 App's exec code
.text.write 0x9d00ad00 0x94 148
.text 0x9d00ad94 0x80 128 App's exec code
.text._fassert 0x9d00ae14 0x80 128
.text.raise 0x9d00ae94 0x7c 124
.rodata 0x9d00af10 0x70 112 Read-only const
.text 0x9d00af80 0x60 96 App's exec code
.text.main_entry 0x9d00afe0 0x4c 76
.text 0x9d00b02c 0x44 68 App's exec code
.text._bootstrap_except 0x9d00b070 0x38 56
.text._general_exceptio 0x9d00b0a8 0x38 56
.text.exit 0x9d00b0e0 0x34 52
.vector_default 0x9d00b114 0x30 48
.text.signal 0x9d00b144 0x30 48
.text._fprintf_cdnopsux 0x9d00b174 0x2c 44
.text 0x9d00b1a0 0x7c 124 App's exec code
.text.abort 0x9d00b21c 0x18 24
.text._on_reset 0x9d00b234 0x8 8
.text._on_bootstrap 0x9d00b23c 0x8 8
.text._cleanup 0x9d00b244 0x8 8
Total kseg0_program_mem used : 0x684c 26700 23.8% of 0x1b5ff

kseg0 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
Total kseg0_boot_mem used : 0 0 <1% of 0x570

Exception-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.app_excpt 0x9d003180 0x10 16 General-Exception
.vector_0 0x9d003200 0x8 8 Interrupt Vector 0
.vector_1 0x9d003220 0x8 8 Interrupt Vector 1
.vector_2 0x9d003240 0x8 8 Interrupt Vector 2
.vector_3 0x9d003260 0x8 8 Interrupt Vector 3
.vector_4 0x9d003280 0x8 8 Interrupt Vector 4
.vector_5 0x9d0032a0 0x8 8 Interrupt Vector 5
.vector_6 0x9d0032c0 0x8 8 Interrupt Vector 6
.vector_7 0x9d0032e0 0x8 8 Interrupt Vector 7
.vector_8 0x9d003300 0x8 8 Interrupt Vector 8
.vector_9 0x9d003320 0x8 8 Interrupt Vector 9
.vector_10 0x9d003340 0x8 8 Interrupt Vector 10
.vector_11 0x9d003360 0x8 8 Interrupt Vector 11
.vector_12 0x9d003380 0x8 8 Interrupt Vector 12
.vector_13 0x9d0033a0 0x8 8 Interrupt Vector 13
.vector_14 0x9d0033c0 0x8 8 Interrupt Vector 14
.vector_15 0x9d0033e0 0x8 8 Interrupt Vector 15
.vector_16 0x9d003400 0x8 8 Interrupt Vector 16
.vector_17 0x9d003420 0x8 8 Interrupt Vector 17
.vector_18 0x9d003440 0x8 8 Interrupt Vector 18
.vector_19 0x9d003460 0x8 8 Interrupt Vector 19
.vector_20 0x9d003480 0x8 8 Interrupt Vector 20
.vector_21 0x9d0034a0 0x8 8 Interrupt Vector 21
.vector_22 0x9d0034c0 0x8 8 Interrupt Vector 22
.vector_23 0x9d0034e0 0x8 8 Interrupt Vector 23
.vector_24 0x9d003500 0x8 8 Interrupt Vector 24
.vector_25 0x9d003520 0x8 8 Interrupt Vector 25
.vector_26 0x9d003540 0x8 8 Interrupt Vector 26
.vector_27 0x9d003560 0x8 8 Interrupt Vector 27
.vector_28 0x9d003580 0x8 8 Interrupt Vector 28
.vector_29 0x9d0035a0 0x8 8 Interrupt Vector 29
.vector_30 0x9d0035c0 0x8 8 Interrupt Vector 30
.vector_31 0x9d0035e0 0x8 8 Interrupt Vector 31
.vector_32 0x9d003600 0x8 8 Interrupt Vector 32
.vector_33 0x9d003620 0x8 8 Interrupt Vector 33
.vector_34 0x9d003640 0x8 8 Interrupt Vector 34
.vector_35 0x9d003660 0x8 8 Interrupt Vector 35
.vector_36 0x9d003680 0x8 8 Interrupt Vector 36
.vector_37 0x9d0036a0 0x8 8 Interrupt Vector 37
.vector_38 0x9d0036c0 0x8 8 Interrupt Vector 38
.vector_39 0x9d0036e0 0x8 8 Interrupt Vector 39
.vector_40 0x9d003700 0x8 8 Interrupt Vector 40
.vector_41 0x9d003720 0x8 8 Interrupt Vector 41
.vector_42 0x9d003740 0x8 8 Interrupt Vector 42
.vector_43 0x9d003760 0x8 8 Interrupt Vector 43
.vector_44 0x9d003780 0x8 8 Interrupt Vector 44
.vector_45 0x9d0037a0 0x8 8 Interrupt Vector 45
.vector_46 0x9d0037c0 0x8 8 Interrupt Vector 46
.vector_47 0x9d0037e0 0x8 8 Interrupt Vector 47
.vector_48 0x9d003800 0x8 8 Interrupt Vector 48
.vector_49 0x9d003820 0x8 8 Interrupt Vector 49
.vector_50 0x9d003840 0x8 8 Interrupt Vector 50
.vector_51 0x9d003860 0x8 8 Interrupt Vector 51
.vector_52 0x9d003880 0x8 8 Interrupt Vector 52
.vector_53 0x9d0038a0 0x8 8 Interrupt Vector 53
.vector_54 0x9d0038c0 0x8 8 Interrupt Vector 54
.vector_55 0x9d0038e0 0x8 8 Interrupt Vector 55
.vector_56 0x9d003900 0x8 8 Interrupt Vector 56
.vector_57 0x9d003920 0x8 8 Interrupt Vector 57
.vector_58 0x9d003940 0x8 8 Interrupt Vector 58
.vector_59 0x9d003960 0x8 8 Interrupt Vector 59
.vector_60 0x9d003980 0x8 8 Interrupt Vector 60
.vector_61 0x9d0039a0 0x8 8 Interrupt Vector 61
.vector_62 0x9d0039c0 0x8 8 Interrupt Vector 62
.vector_63 0x9d0039e0 0x8 8 Interrupt Vector 63
Total exception_mem used : 0x210 528 12.9% of 0x1000

kseg1 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.reset 0x9d004000 0x1c4 452 Reset handler
.bev_excpt 0x9d004380 0x10 16 BEV-Exception
Total kseg1_boot_mem used : 0x1d4 468 40.1% of 0x490
--------------------------------------------------------------------------
Total Program Memory used : 0x6c30 27696 23.3% of 0x1cfff
--------------------------------------------------------------------------


kseg1 Data-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.eh_frame 0xa0000000 0x30 48
.sdata 0xa0000030 0xc 12 Small init data
.sbss 0xa000003c 0x18 24 Small uninit data
.bss 0xa0000054 0x110 272 Uninitialized data
.data 0xa0000164 0x84 132 Initialized data
.bss 0xa00001e8 0x18 24 Uninitialized data
.bss 0xa0000200 0x1d8 472 Uninitialized data
.data 0xa00003d8 0xa0 160 Initialized data
.bss 0xa0000478 0x40 64 Uninitialized data
.data 0xa00004b8 0x24 36 Initialized data
.data 0xa00004dc 0x10 16 Initialized data
Total kseg1_data_mem used : 0x4ec 1260 3.8% of 0x8000
--------------------------------------------------------------------------
Total Data Memory used : 0x4ec 1260 3.8% of 0x8000
--------------------------------------------------------------------------


Dynamic Data-Memory Reservation
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
heap 0xa00004f0 0x10 16 Reserved for heap
stack 0xa0000518 0x7ad8 31448 Reserved for stack


I was expecting that compiling it with the modified elf32pic32mx.ld linker file will result only in a code offset due to bootloader usage. Instead the generated memory usage is for the same project



Microchip PIC32 Memory-Usage Report

kseg0 Program-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.text 0x9d004a00 0x1184 4484 App's exec code
Driver 0x9d005b84 0xec8 3784
.text._vfprintf_cdnopsu 0x9d006a4c 0xad0 2768
.text 0x9d00751c 0x140c 5132 App's exec code
Driver 0x9d008928 0x458 1112
.text 0x9d008d80 0x868 2152 App's exec code
.rodata 0x9d0095e8 0x3cc 972 Read-only const
.dinit 0x9d0099b4 0x280 640
.text 0x9d009c34 0x6b8 1720 App's exec code
.text.fputc 0x9d00a2ec 0x15c 348
.text 0x9d00a448 0x278 632 App's exec code
.text._flsbuf 0x9d00a6c0 0x12c 300
.rodata 0x9d00a7ec 0x220 544 Read-only const
.text.general_exception 0x9d00aa0c 0xdc 220
.rodata 0x9d00aae8 0xd0 208 Read-only const
.text._mon_putc 0x9d00abb8 0xb4 180
.text 0x9d00ac6c 0x94 148 App's exec code
.text.write 0x9d00ad00 0x94 148
.text 0x9d00ad94 0x80 128 App's exec code
.text._fassert 0x9d00ae14 0x80 128
.text.raise 0x9d00ae94 0x7c 124
.rodata 0x9d00af10 0x70 112 Read-only const
.text 0x9d00af80 0x60 96 App's exec code
.text.main_entry 0x9d00afe0 0x4c 76
.text 0x9d00b02c 0x44 68 App's exec code
.text._bootstrap_except 0x9d00b070 0x38 56
.text._general_exceptio 0x9d00b0a8 0x38 56
.text.exit 0x9d00b0e0 0x34 52
.text.signal 0x9d00b114 0x30 48
.text._fprintf_cdnopsux 0x9d00b144 0x2c 44
.text 0x9d00b170 0x7c 124 App's exec code
.text.abort 0x9d00b1ec 0x18 24
.text._on_reset 0x9d00b204 0x8 8
.text._on_bootstrap 0x9d00b20c 0x8 8
.text._cleanup 0x9d00b214 0x8 8
Total kseg0_program_mem used : 0x681c 26652 23.8% of 0x1b5ff

kseg0 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
Total kseg0_boot_mem used : 0 0 <1% of 0x570

Exception-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.app_excpt 0x9d003180 0x10 16 General-Exception
.vector_0 0x9d003200 0x8 8 Interrupt Vector 0
.vector_30 0x9d0035c0 0x8 8 Interrupt Vector 30
Total exception_mem used : 0x20 32 0.8% of 0x1000

kseg1 Boot-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.reset 0x9d004000 0x1c4 452 Reset handler
.bev_excpt 0x9d004380 0x10 16 BEV-Exception
Total kseg1_boot_mem used : 0x1d4 468 40.1% of 0x490
--------------------------------------------------------------------------
Total Program Memory used : 0x6a10 27152 22.9% of 0x1cfff
--------------------------------------------------------------------------


kseg1 Data-Memory Usage
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
.eh_frame 0xa0000000 0x30 48
.sdata 0xa0000030 0xc 12 Small init data
.sbss 0xa000003c 0x18 24 Small uninit data
.bss 0xa0000054 0x110 272 Uninitialized data
.data 0xa0000164 0x84 132 Initialized data
.bss 0xa00001e8 0x18 24 Uninitialized data
.bss 0xa0000200 0x1d8 472 Uninitialized data
.data 0xa00003d8 0xa0 160 Initialized data
.bss 0xa0000478 0x40 64 Uninitialized data
.data 0xa00004b8 0x24 36 Initialized data
.data 0xa00004dc 0x10 16 Initialized data
Total kseg1_data_mem used : 0x4ec 1260 3.8% of 0x8000
--------------------------------------------------------------------------
Total Data Memory used : 0x4ec 1260 3.8% of 0x8000
--------------------------------------------------------------------------


Dynamic Data-Memory Reservation
section address length [bytes] (dec) Description
------- ---------- ------------------------- -----------
heap 0xa00004f0 0x10 16 Reserved for heap
stack 0xa0000518 0x7ad8 31448 Reserved for stack


Here we see that the memory program and data regions are reallocated according the bootloader memory configuration but in the interrupt section only two vector are mapped .vector_0 and .vector_30.
I suspect that the cdc demo use more interrupts vector that arent allocate so the code does not work as intended.
However i tested several simple application that works with the modify elf so this problem exploits only for huge and complex code. However i'm stuck at the point i dont know how to preceed.
So what do you think ??
Reply
22-01-2014, 12:17 PM,
#18
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Linker files that Pinguino use are different than MPLAB. They are much older while Microchip added/changed stuff along the way. I also noticed differences with bus matrix stuff because new MPLAB compiler calculates some things internally, and in older, Pinguino they are calculated from within linker script code. So, you can't compile latest MPLAB linker files with pinguino toolchain without that definitions.There might be a lot more stuff that are different and are just causing problems when compiling in MPLAB.

It would be best if you copy original MPLAB linker files and just modify procdefs.ld (by looking pinguino one) with kseg memory addresses that will tako into account bootloader location so it is not overwritten.

I'm not sure why there are no more vectors, but USB only uses one vector and that is probably vector_30 for your board (vector_45 for OTG). Vector_0 is something else from datasheet.
Dreaming in Code...
Reply
10-02-2014, 12:24 AM,
#19
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
I'm happy ... few second ago i've been able in MPLAB_X to compile and run for the first time the
Harmony CDC_com_port_single demo example on the PIC32_DIY board.

At this time i programmed the code with pickit3 so the PIC32MX250F128B does not have any bootloader. Now i'm testing what happen with the bootloader.

However i found some weird behaviour. In Windows 7 since i already had installed the CDC driver the device has been immediately enumerated as a serial port. Has been assigned to COM15 and using putty i was able to connect and read characters and the "Button Pressed" message.

In Linux OpenSuse 13.1 device has been immediately enumerated but dmesg reports this

[ 812.023139] usb 3-2: new full-speed USB device number 4 using ohci_hcd
[ 812.215285] usb 3-2: config index 0 descriptor too short (expected 66, got 9)
[ 812.215292] usb 3-2: config 1 has 0 interfaces, different from the descriptor's value: 2
[ 817.225452] usb 3-2: New USB device found, idVendor=04d8, idProduct=000a
[ 817.225462] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 817.225467] usb 3-2: Product: Simple CDC Device Demo
[ 817.225471] usb 3-2: Manufacturer: Microchip Technology Inc.

so something is not good with the usb descriptors. The weird thing is that windows does not care about and it work ... i don't know what to think...
Reply
10-02-2014, 06:32 PM,
#20
RE: PIC32 DIY and MPLAB-Harmony CDC Single Com Demo
Windows may not follow the standard and may not log that the descriptor is wrong. Sounds like the sample needs fixing.

John
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)