Page 15 of 19
Re: TF Riser Revision 0 Arrives
Posted: 11 Mar 2020 22:11
by terriblefire
arkadiusz.makarenko wrote: 11 Mar 2020 22:04
terriblefire wrote: 11 Mar 2020 19:32
I've tried firing it up and with one device i always get hardfaults and the other i get...
hardfault.JPG
Basically looks like the 105 doesnt have the RAM for what we're trying to do
This can only happen on usb disconnects. There must be a bug which screws something up.(I suspect mouse init - buffer length allocation). I will try to investigate this.
I have built hid2ami and written my own firmware on f105, and devices which I have at home do behave, so only way forward is to find more devices and trace this issue.
I'll try this in the morning. I am seeing it crash on a malloc during init.
Re: TF Riser Revision 0 Arrives
Posted: 11 Mar 2020 22:30
by arkadiusz.makarenko
Maybe heap and stack is set too low?
It never solved any of my issues, but who knows maybe this time?
Re: TF Riser Revision 0 Arrives
Posted: 12 Mar 2020 12:10
by arkadiusz.makarenko
I think I will remove malloc and create concrete instances on pData array. This way I will break "universal" character of this library, it will be only for HID devices, but this way memory will be allocated for HID_Handlers this from the start.
Re: TF Riser Revision 0 Arrives
Posted: 12 Mar 2020 17:55
by terriblefire
Code: Select all
002:002:001:DESCRIPTOR 1584035698.286893
05 01 09 02 A1 01 85 02 09 01 A1 00 05 09 19 01
29 10 15 00 25 01 95 10 75 01 81 02 05 01 16 01
F8 26 FF 07 75 0C 95 02 09 30 09 31 81 06 15 81
25 7F 75 08 95 01 09 38 81 06 05 0C 0A 38 02 95
01 81 06 C0 C0 05 0C 09 01 A1 01 85 03 75 10 95
02 15 01 26 8C 02 19 01 2A 8C 02 81 00 C0 05 01
09 80 A1 01 85 04 75 02 95 01 15 01 25 03 09 82
09 81 09 83 81 60 75 06 81 03 C0 06 00 FF 09 01
A1 01 85 10 75 08 95 06 15 00 26 FF 00 09 01 81
00 09 01 91 00 C0 06 00 FF 09 02 A1 01 85 11 75
08 95 13 15 00 26 FF 00 09 02 81 00 09 02 91 00
C0
002:002:000:DESCRIPTOR 1584035698.303352
05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
75 01 95 08 81 02 81 03 95 05 05 08 19 01 29 05
91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 A4
00 05 07 19 00 2A A4 00 81 00 C0
Re: TF Riser Revision 0 Arrives
Posted: 12 Mar 2020 19:52
by arkadiusz.makarenko
@terriblefire
My device has exactly the same HID descriptors...
It must be memory allocation issue :/
EDIT:
YEY. I managed to reproduce the bug. I am on it :)
Arek
Re: TF Riser Revision 0 Arrives
Posted: 12 Mar 2020 21:09
by arkadiusz.makarenko
@terriblefire
Could you try this firmware?
I replaced malloc with global initialization, and it behaves now on my build.
I have replaced f730 with new f105. We should be on the same page now.
I know it is crude, but apparently using malloc on microcontrollers is not recommended. I cannot run away form it, as I need to allocate dynamic size for each hid report, but apparently less is better.
https://github.com/arkadiuszmakarenko/TFRiserF105
Re: TF Riser Revision 0 Arrives
Posted: 12 Mar 2020 21:16
by terriblefire
Ok i'll try get to test this ASAP
Re: TF Riser Revision 0 Arrives
Posted: 13 Mar 2020 20:02
by arkadiusz.makarenko
It looks that we are in fact running out of memory, but I had this for a moment on 256k RAM, so it did suggest that there is memory leak.
When I removed banner() and commented all printf() there was enough for normal operation. I need to investigate implementation and configuration of printf(), as it appears like ram was never free() after use?
Re: TF Riser Revision 0 Arrives
Posted: 13 Mar 2020 21:19
by terriblefire
arkadiusz.makarenko wrote: 13 Mar 2020 20:02
It looks that we are in fact running out of memory, but I had this for a moment on 256k RAM, so it did suggest that there is memory leak.
When I removed banner() and commented all printf() there was enough for normal operation. I need to investigate implementation and configuration of printf(), as it appears like ram was never free() after use?
Yes i found this. Printf with params leaks like crazy but i never tracked it down.
Re: TF Riser Revision 0 Arrives
Posted: 14 Mar 2020 14:33
by terriblefire
Ok no crashes but the mouse delta types are all screwed up from what i originally posted.
Mouse datacomes from the mouse as an unsigned byte which needs to be cast to a signed byte (128-255) -ve, (0-127) +ive...
this needs to be accumulated in the buffer as a signed 16 bit because you can get multiple mouse events per transmission to the amiga.
You accumulate this in a further layer to emulate joy0dat and joy1dat.
You are sending the raw joy0dat and joy1dats to the CPLD. its dumb and doesnt have the gates to do math.