A raspberry pi could do it, as would a dedicated SPI flash programmer, possibly an arduino using 3.3v logic. Since it's running a relatively sophisticated processor for an arguably dumb device, there is a small chance the byte header OP mentioned, or elsewhere contains a checksum to prevent tampering. If the header contains it, that's a relatively easy fix though. On first run, I'd pull the file, most likely wav, note the format, number of channels, sample rate and bit depth, you'll likely want, if not need to match these parameters in creating the audio file you want. Create the file of your choosing, then prefix it with the header OP mentioned. Flash using a chip clip and the device you chose.
It should be a relatively straightforward process, but if anyone is willing to do it with their own hardware I'm willing to offer what help I can. I haven't flashed any modules in this manner in over 20 years. I could probably admit to why I flashed chips now, statue of limitations and all, but I won't
Raspberry Pi may be overkill, I was thinking of using a ESP32 to interface to a mobile phone and change the tones on the fly... Well from preselected sounds. The ROM Dump that I did has some other code in it that I'm not sure we can break. BUT a fallback would be to just replace the module and mimick it. The Module is connected to CANBUS and Power, and the speaker.
Yeah, work gets the best of all of us. As far as the pi goes, I was specifically referring to using it and flashrom to reprogram the flash. Although I'm sure the Pi, amp and speaker could be used to make your own pedestrian programmable speaker... Glad you're alive and well, sounded like some people were worried about ya. If you still have the file around, can you post the 16 byte header from the dump.
I can't upload the dump here.. There are 300 bytes of data @ 0xffe80 in the dump. This may be a crypto signature, which would be nearly impossible to decode. I bought 10 flash chip to play with but no luck in decoding the code. At least one other member on this page was also working on this. The audio seems to be 32 bit stereo encoded @ 22050 sampling rate.
the first few bytes should tell you if it's write protected, I'll take a look when I get back home, don't know if this is the exact chip used but the datasheet is here
Oops, I guess I incorrectly assumed the status register was at 00000000h since it lined up cleanly enough with what you described as a header, it's actually a separate SPI command to read them. Any idea what the result was? Did they attempt to raise pin 3 to high? If reflashing gave an error or just failed silently, as in it kept the previous programming, that certainly would suggest it was write protected. Raising pin 3 to high may allow it to be rewritten anyway. If the flash was rewritten, that means some kind of checksum or other layered protection was in place. If that were the case, then obviously the only remaining option so changing the sounds is building the custom module, which if we're being honest here, is likely to be the easiest to do anyway.Yes that is the chip:
First couple of lines look like this:
Here are those 300 bytes @ 000ffe80 that is really of concern.
There is another member on this forum that has tried to flash the chip with a new sound file, without success.
Wondering.... Could I change the pedestrian warning sounds?
I picked up a spare to play with via ebay.... This is located under the glove box.
Pretty simple device, 6 wires in and out. Power, Ground, CANBUS high and low and a speaker.
Cracked it open and identified the chips..
ARM processor, Amp chip on one side:
Op Amp, Line Driver and Flash memory on the bottom.
Dumped the Flash chip and low and behold... Our truck sounds.
Interestingly how they did it...
The Left Channel is the running sound.
While the Right Channel is the backup sound.
Which sounds like this:
(Couldn't upload audio files here.... so converted them to blank videos).
Backing up (Left Channel)
Driving (Right Channel)
