• AVR Freaks

Helpful ReplyHot!MZ Bootloader Automount USB Host/MSD Troubleshooting

Author
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
2020/01/23 12:31:17 (permalink)
0

MZ Bootloader Automount USB Host/MSD Troubleshooting

I would like to tap into the expertise in the community here to understand how best to troubleshoot a custom bootloader.  I am working with a  PICMZ1024EFG100 part on a custom board.  A USB MSD drive is inserted and the bus 5V is driven externally.  VBUS has already been troubleshot? and is working correctly.  The PIC is configured as a host and clocks are setup appropriately to enable USB.
 
Just getting USB I/O using the filesystem to work correctly seemed like a big win.  I'm more from a hardware background than software so it has been somewhat challenging.  I can successfully open and write a file to a USB MSD device but when I attempt to use Harmony to use the exact same configuration but then add the bootloader function, it does not progress through the bootloader state machine.
 
I added the bootloader function by selecting bootloader from the Harmony menu, setting it as USB_HOST type and add as bootloader (not application with linker script).  I'll note here that I'm developing on a Mac running MPLABX 5.30 using Harmony v2.0.5.2.  I have a Windows 10 machine with MPLABX 5.3 with Harmony v3 installed but found that the bootloader function doesn't seem to include USB support anymore?? ? so the project is entirely in Harmony v2.
 
I have researched through many forum posts and examples and found the exact implementation I wanted in "Harmony Housecalls" from April 2016 in their lab 2a.  The example uses Harmony v1 and a BSP board but does it simply without adding extra code.  So here I am thinking the bootloader should run through its state machine when I insert the USB stick.  It does interact with the device and cause the lighting function to activate on the drive indicating something has happened over USB and the device is powered or ???  I'm puzzled at the state of the device since the file i/o operation behaved the same way but wrote to the drive.  Now when it lights up I get no break points happening at case BOOTLOADER_DEVICE_CONNECTED.  It just sits at case BOOTLOADER_WAIT_FOR_HOST_ENABLE with the first test failing.
if((bootloaderData.streamHandle) == DRV_CLIENT_STATUS_READY
{...
}
bootloaderData.streamHandle is 0xFFFFFFFF or DRV_CLIENT_STATUS_ERROR
 
I'll include the state of bootloaderData object below.  Not sure how to do that inline.
 
The state machine halts at bootloaderData.currentState == BOOTLOADER_WAIT_FOR_HOST_ENABLE and stays there.
 
I don't know exactly what the USB layers are doing or it *might* be easier to debug.  A "theory of operation" or a "design intent" might go a long way if included in the beginning of the bootloader.h or .c files.  That said, it seems like I should not need to be diving into middleware to find the problem.
 
Part of the issue for me seems to be that if breakpoints are used the interrupt-driven nature of the file system gets broken and things don't process correctly.  So from my debug point of view I need to know what to look at to insert the correct break points.  That is probably my main problem.  I don't know where to insert the break points to accurately diagnose the issue with a stalled bootloader waiting to open a file.  Anyone have any insights on how to properly diagnose my stalled bootloader?
 
Here are some extras:
-------------------------------------
Bootloader States:
-------------------------------------
typedef enum
{
/* Application's state machine's initial state. */
BOOTLOADER_STATE_INIT=0,
/* Check to see if we need to force the bootloader */
BOOTLOADER_CHECK_FOR_TRIGGER,
/* If we need to program, then open the datastream. */
BOOTLOADER_OPEN_DATASTREAM,
/* The application gets a command from the host application. */
BOOTLOADER_GET_COMMAND,
/* The application processes the command from the host application. */
BOOTLOADER_PROCESS_COMMAND,
/* The application waits for the NVM operation to complete. */
BOOTLOADER_WAIT_FOR_NVM,
/* The application sends data back to the user. */
BOOTLOADER_SEND_RESPONSE,
/* The application waits in this state for the driver to finish
sending/receiving the message. */
BOOTLOADER_WAIT_FOR_DONE,

BOOTLOADER_CLOSE_DATASTREAM,
/* The application enters the user application. */
BOOTLOADER_ENTER_APPLICATION,

BOOTLOADER_RESET,
BOOTLOADER_OPEN_FILE,
BOOTLOADER_READ_FILE,
BOOTLOADER_WAIT_FOR_DEVICE_ATTACH,
BOOTLOADER_WAIT_FOR_HOST_ENABLE,
BOOTLOADER_DEVICE_CONNECTED,
BOOTLOADER_UNMOUNT_DISK,
BOOTLOADER_SWITCH_APPLICATION,
/* This state indicates an error has occurred. */
BOOTLOADER_ERROR,
} BOOTLOADER_STATES;
 

Attached Image(s)

#1
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/24 10:23:05 (permalink)
0
--> UPDATE <--
Yikes, I got it working using a new installation of MPLABX on a Windows 10 machine rather than the Mac.  I had installed Harmony 3 on this machine but as I mentioned in the original post there doesn't seem to be support for USB-host bootloading yet.
 
What I was seeing in the original environment was successful builds but then in the IDE I noticed that some code was greyed out.  This code in the bootloader was greyed out because a #define in the system_config.h file wasn't visible to the bootloader.h where it was referenced.  The files were there, the calls were there, but not being imported for some reason.
 
I decided to start fresh which is why I switched to the Windows machine and installed Harmony v2 on that.  The first attempt with the new build worked fine.  Yikes.  The only theory I have is that something in a default file got changed inadvertently from another project and was imported into the bootloader project where it caused the problem.
 
So I'll still ask my original question...  how do you approach the debug process and step through interrupt-driven file system code like the bootloader so that you don't mess-up the enumeration process (or whatever it needs to do in real-time?)
 
Thanks!
#2
NKurzman
A Guy on the Net
  • Total Posts : 18663
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/24 11:02:20 (permalink)
0
I can Say the V2.06 USB MSD Bootloader works with many Sticks.  But It has a bug that Stops some sticks from Enumerating.  Note: the Sticks must be FAT32.
Is you USB Hardware the same as Microchips?  Bus Power and Bus Fault Pins Handled? VBUS?
 
You May want to get a Microchip Board with a similar Chip, That way you can try the sample Apps.
Make sure the Sample Supports your Eval Board. Maybe DM320007
#3
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/29 13:17:16 (permalink)
0
Just to be clear, I was able to get the USB working but your comment is somewhat prophetic.  The bootloader only works with maybe 20% of USB drives I've sampled.  (I have another problem with the linker script on another thread you might have insight on.)
 
Regarding the hardware, 5V is powered externally and VBUS is tied directly to 5V.  That was quite a process to figure out in and of itself since the project moved from an MX part to MZ.  Another forum post steered me in the right direction on that.
 
Do you know what the bug is in the enumeration process for some drives?  We are very near to ordering a USB analyzer to see where it breaks.  I can say that so far all Lexar branded drives work but only a smattering of other drives work.  When I say Lexar is recognized, I mean all sizes - 4GB to 256GB in FAT32 and exFAT formats.
 
I've read a lot of your responses on this forum.  You've contributed quite a lot.  Thank you!
#4
NKurzman
A Guy on the Net
  • Total Posts : 18663
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/29 13:46:13 (permalink)
0
The Driver Only Supports FAT32 so that means anything above 32Gig will not work.
Those should Enumerate, but not Register with the File System.
 
The Issue isdrv_usbhs_host.c in State DRV_USBHS_HOST_RESET_STATE_WAIT_FOR_COMPLETE
This cause some sticks to not even enumerate.
 
The V3.XX Harmony USB Sample code works in the Starter kit.  But I do not know how well 3.XX is doing with MIPS in other repects.  Note there is only a limited migration path from V2 to V3
 
#5
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/29 19:42:20 (permalink)
0
I'm puzzled why the Lexar drives all work then.  They enumerate, register, open, read, write, close all fine.  Everything from 4GB to 256GB. I have many drives to test and the 4, 8, 16, 32, 64, 128, and 256GB Lexar drives ALL work with our MZ part.
 
The larger drives are all formatted as exFat and still operate correctly using the Harmony v 2.0.5.2 framework USB host services, file system services, and bootloader.
 
Also, I understand there are numerous upgrade issues. I started down the path going to version 3 and as soon as I tried to place the bootloader block I realized no USB support was present.  Only UART.  I disabled the plugin and revisited all my prior issues in v2.
post edited by mdehaven - 2020/01/29 19:46:30
#6
NKurzman
A Guy on the Net
  • Total Posts : 18663
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/29 23:56:40 (permalink)
0
Then I guess I am wrong about drives bigger than 32 gig.
You can use a V2.XX bootloader with a V3.XX app.
Or you can add usb to the serial bootloader.
#7
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/30 07:17:33 (permalink)
0
I plan to do the former, building the bootloader in V2 and then code application in V3.  I wish I understood how to build the USB link between the bootloader UART input in V3 but I'm very new to Harmony so if it isn't straightforward I'm hamstrung.
 
My hurdle now is with the linker script.  I've posted this issue here: https://www.microchip.com/forums/m1126353.aspx
#8
NKurzman
A Guy on the Net
  • Total Posts : 18663
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/30 08:46:55 (permalink)
0
I have not looked at the V3 boot loader.
in the V2 Boot loader there is a "library" File bootloader.C  that pulls Data from a datastream file.  You can find theses in the Harmony Framework source code.
I my opinion the "bootloader.c" was a bad idea it is just a wrapper around some sample code.  I pulled it out and put it in the main loop so that I could tailor it to my needs and make it more robust.
#9
mdehaven
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2020/01/18 10:07:18
  • Location: Indiana
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/30 09:19:47 (permalink)
0
I used the bootloader since the concept of USB enumeration/file system access in PIC32 was completely foreign to me a few weeks ago.  When it didn't work right away I was in a world of pain trying to understand how it was built.  This thread is an example of that.  I had no idea how to debug the USB code and now realize there may not be a good step-through answer for that since the USB process requires time-dependent responses.
 
Your solution to move the bootloader.c into your main loop is a good one.  I think you or someone else posted that moving it to the app.c file is good since the templates get screwed up once you start changing things in the framework generated files.  I don't yet know how to prevent that from happening unless you do just that, move the code to the app.c or main file.
#10
NKurzman
A Guy on the Net
  • Total Posts : 18663
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: MZ Bootloader Automount USB Host/MSD Troubleshooting 2020/01/30 10:18:50 (permalink) ☄ Helpfulby mdehaven 2020/01/30 12:41:35
0
What I did was:
-check the Bootloader Box.
-Create the Application Linker script.
-Copy the Bootloader State machine to the Main one.
-Unchecked the Bootloader Box.
-Now it is a Standalone Program with the Correct Bootloader Linker script.
For PIC32 that is all a Bootloader is.  A normal Program, just size limited.
The Application Linker script is more elaborate.
 
I have not looked at what they did for the V3 Bootloader.
 
The provide two key pieces for a Bootloader
1. The Intel hex File Parser.
2.The Flash write Functions.
 
 
 
#11
Jump to:
© 2020 APG vNext Commercial Version 4.5