MSP432E401Y: BSL-Scripter Bootloader issue: [ERROR_MESSAGE]There is invalid TFTP Read Request in the packet received!

Are you on a private network, or a public(-ish) network?

When I worked with this last year, one failure mode was having another DHCP/BOOTP server (somewhere else on the network) respond to the initial request. Since this other server didn't know anything about the MSP432, it supplied a null (0-length) load filename along with the IP address. When the MSP432 in turn echoed this (null) string to the TFTP server (BSL-Scripter this time) it was reported as an invalid TFTP request, due to the null filename. 

I recall a slightly different error message (equally non-specific) so BSL-Scripter might have changed in the meantime.

Wireshark traces would tell us whether this happened. If you're in a position to disconnect from your corporate/lab network, so it's just your board and your PC on the net, that might be a useful experiment.

Bruce thanks for your response,

Because of the current situation, I am testing on 2 networks: at home and remote connect to a second dev board at my company. Both networks do not work. At my home network I do have a raspberry pi running https://pi-hole.net/ Which is a DHCP server and DNS so I guess that could be causing the Bootp conflict.

I am able to provide a few seconds of wireshark capture of my network at home: enough to capture entire BSL-Scripter run. I would need more time to figure out the situation at my company though.

If multiple DHCP servers running could be an issue. Do you think there is a way to make this more robust so that the bootloader only listens to BSL-Scripter? In a new product using this micro, if a customer would like to update firmware it would be better to be robust and not restrict their networks in any way.

Changing to extension of this file to pcapng should allow someone to open this in wireshark:

�M<+
��������5Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (with SSE4.2)%64-bit Windows 10 (1909), build 183632Dumpcap (Wireshark) 3.2.3 (v3.2.3-0-gf39b50865a13)�
�
2\Device\NPF_{03336A9F-8D95-4EDE-AD47-063A60DE3B48}Ethernet	
%64-bit Windows 10 (1909), build 18363�\���<<��������:

��:��

��
!\X��,66���`\�
EͱE(�@�\���
��
���H>�윬�ɲP���X\�3<<
Eͱ���`\�E(I@@m���
���
H����ɲ>��P��
\X�<366���`\�
EͱE(�@�\���
��
���H>�읬�ɳP���X�� c^^�������8�^e�EPac�0��
b����� <J�192.168.1.98:8193:DESKTOP-4T4O4A1:1.3.1438:3:1180049�\���<<��������:

��:��

��
!\x
��:$V
V
������p�vYIE
H
@y�����DC
4�%

]i�>
p�vYItivax
\�C�-<<
Eͱ��:E(�9@@/��

��

���9l�����P��\X�e�-66��:
EͱE(��@����
��

��
�����9l�P oCXx
��3V
V
������p�vYIE
H@y�����DC
4��

[.�p�vYItivax
x
�?�RV
V
������p�vYIE
H@y�����DC
4��

�#m�p�vYItivax
\�A�a::�8�^e�
EͱE,�[@�����
��
b���Տ�7#F�PX\����a^^�������8�^e�EPad�/��
b����� <J�192.168.1.98:8193:DESKTOP-4T4O4A1:1.3.1438:3:1180049�\��Rb<<
Eͱ�8�^e�E(�@�����
b��
��7#F��Տ�P�b\l��
Counters provided by dumpcap�����l

I don't see any BOOTP reply from anyone in this trace. I vaguely recall that BSL-Scripter reported "invalid packet" when it meant "timeout" (not quite the same thing),and the 3-4 second time lapse between the original request and the end sort of corroborate.

That suggests something more prosaic. Maybe it's a good time to (re-)check the firewall, to see if it ate the outgoing BOOTP response?

I think I have some traces from a successful interchange, but unfortunately not here with me (probably not before next week).

bsl-scripter shows as an app allowed through the firewall in my firewall settings:

I also disabled firewall entirely:

But this is the trace that shows and still no BOOTP reply from host :/

A trace of a successful run and maybe versions used could be helpful but if you have other ideas I'll certainly try those.

I'm not sure what else to suggest about the firewall. As I recall I had to turn off AVG (anti-virus) as well.