DFplayer mini module problems

Ghostbear

Member
Afternoon all.

I've spent the weekend wrestling with this so far and all I've got is frustrated.

I've got a number of the DFplayer mini boards - all have been checked on the SPE035 module and all happily play like good little audio modules.

Taking them off the module and trying to get the serial comms working however has so far been an exercise in futility.

So far:
Tried 4 different DFplayer (just in case)
All possible modes of the Dfplayer playback according to the datasheet
All possible setups on the microsd card for the naming and folder layouts.
Multiple different pins for the transmission of the serial data.

So.. how is it that something that looks fairly straightforward is managing to stump me?
Does anyone have any examples and/or advice?
 

hippy

Technical Support
Staff member
If the DFPlayer Mini module is working on the SPE035 then it should also work when not. It sounds like you have a wiring or circuit error. Check the DFPlayer Mini module is not the wrong way round. Check both GND/0V are connected.

There isn't a circuit diagram in the SPE035 datasheet but shouldn't be too hard to figure out from the datasaheet ...

Code:
5V -------------.---------------------------------------.--
                |                                       |
C.2 BY <--------|-------------------------.             |
                |                         |             |
           1K   |   .-------__--------.   |           __|__
           __   `---| 1 VCC    BSY 16 |---'           --.--
B.4 SO >--|__|------| 2 RX      U- 15 |-           100n |
C.3 SI <------------| 3 TX      U+ 14 |-                |
             .------| 4 R      AK2 13 |-                |
    |\ _   .-|------| 5 L      AK1 12 |----------.      |
    | | |--|-|------| 6 SP-    IO2 11 |--------. |      |
    | | |  | |  .---| 7 0V      0V 10 |---.    | |      |
    | |_|--|-|--|---| 8 SP+    IO1  9 |---|--. | |      |
    |/ +   | |  |   `-----------------'   |  | | |      |
           | |  |                         |  o o o |-.  |
         O O O  |      DFPlayer Mini      |  o o o |-'  |
         |      |                         |  | | |      |
0V ------^------^-------------------------^--^-^-^------^-- 
         G L R                               1 2 3
I don't have an SPE035 board to hand but it should be easy enough to circuit trace the PCB to verify that is correct.

You should be able to get it to work with just this bare minimum ...

Code:
5V -------------.
                |
C.2 BY <--------|-------------------------.
                |                         |
           1K   |   .-------__--------.   |
           __   `---| 1 VCC    BSY 16 |---'
B.4 SO >--|__|------| 2 RX      U- 15 |-
C.3 SI <------------| 3 TX      U+ 14 |-
                   -| 4 R      AK2 13 |-
    |\ _           -| 5 L      AK1 12 |-
    | | |-----------| 6 SP-    IO2 11 |-
    | | |       .---| 7 0V      0V 10 |---.
    | |_|-------|---| 8 SP+    IO1  9 |-  |
    |/ +        |   `-----------------'   |
                |      DFPlayer Mini      |
0V -------------^-------------------------'
 
Last edited:

steliosm

Senior Member
Since I have been using those modules as well for quite some time now, I have noticed that although it's fine to power them using 5 volts you need to include a diode between the PicAxe chip and the Rx pin on the module (pin 2), unless the Picaxe is powered by 3.3 volts. This is also depicted in the diagrams hippy has provided as well.
Also, the LED on the module can be used to give you 'status' information. If the module has been powered up properly you will see a dim light. When it's receiving command this light will flicker and, finally, when it's playing audio the light will be on.
 

Ghostbear

Member
Since I have been using those modules as well for quite some time now, I have noticed that although it's fine to power them using 5 volts you need to include a diode between the PicAxe chip and the Rx pin on the module (pin 2), unless the Picaxe is powered by 3.3 volts. This is also depicted in the diagrams hippy has provided as well.
Also, the LED on the module can be used to give you 'status' information. If the module has been powered up properly you will see a dim light. When it's receiving command this light will flicker and, finally, when it's playing audio the light will be on.
Diode or resistor? Data sheet mentions resistor...
 

Ghostbear

Member
DFplayer - poss serout issue?

The SPE035 board uses a 1K resister, as per datasheet.
Thats handy as that's what I was using :)

However, I think I've tracked down 2 problems - 1 was a dodgy breadboard so power was intermittant - which is ironic as I'd moved it to that breadboard in case of dodgy connections on the other. Typical :)

The second thing, and to me more puzzling, but possibly the root cause is the 1st serout command to initialise the module.

the command is
Code:
cmd=$09:arg=$00
SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
The corresponding command to play a track is
Code:
cmd=$03:arg=$01
SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
BUT when ran in simulation, the Serial TYerminal Simulation window show the commands as:
Code:
send configuration
~[FF][06]   [00][00][00][EF]
play track
~[FF][06][03][00][00][01][EF]
play track
Missing the command for the initialisation so it doesnt appear to be setting up the module......

Either tat or I'm missing someting simple as the wiring is setup as:
Code:
5V -------------.
                |
                |                         |
           1K   |   .-------__--------.   |
           __   `---| 1 VCC    BSY 16 |-
B.1 SO >--|__|------| 2 RX      U- 15 |-
                   -| 3 TX      U+ 14 |-
                   -| 4 R      AK2 13 |-
    |\ _           -| 5 L      AK1 12 |-
    | | |-----------| 6 SP-    IO2 11 |-
    | | |       .---| 7 0V      0V 10 |---.
    | |_|-------|---| 8 SP+    IO1  9 |-  |
    |/ +        |   `-----------------'   |
                |      DFPlayer Mini      |
0V -------------^-------------------------'
and for reference the code is:
Code:
Symbol BAUD_FREQ = M8
Symbol BAUD = T9600_8
Symbol arg = w2 ; b5:b4
Symbol arg.lsb = b4
Symbol arg.msb = b5
Symbol TX = B.1
Symbol cmd = b6

SETFREQ M32

init:
high TX
SerTxd(CR,LF,"send configuration",CR,LF)
cmd=$09:arg=$00:gosub Sendaudio
pause 4000

main:
	pause 250
	SerTxd(CR,LF,"play track",CR,LF)
	cmd =$03: arg=$0001:Gosub Sendaudio ; play track 1
	pause 500
	goto main

end


Sendaudio:
SetFreq BAUD_FREQ
Pause 10
SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
pause 10
SetFreq M32

Return

Over to you Hivemind and thanks again :) This as been driving me potty tis weekend.
 

The bear

Senior Member
SPE035 Serial Audio Module (04.12.15) Date is for info, only.
A search found this thread, maybe of some use?

Regards, bear..
 

hippy

Technical Support
Staff member
BUT when ran in simulation, the Serial TYerminal Simulation window show the commands as:
Code:
send configuration
~[FF][06]   [00][00][00][EF]
play track
~[FF][06][03][00][00][01][EF]
play track
Missing the command for the initialisation so it doesnt appear to be setting up the module......
The $09 is being interpreted by the Terminal display as a TAB character, hence the visual gap between [06] and the [00].

TAB is a printable (though transparent) character. Only non-printable characters are shown as hex values within brackets.
 

Ghostbear

Member
The $09 is being interpreted by the Terminal display as a TAB character, hence the visual gap between [06] and the [00].

TAB is a printable (though transparent) character. Only non-printable characters are shown as hex values within brackets.
I did wonder if it might have been something like that.

Ah well,back to square one.

Anyone have any suggestions??
 

tmfkam

Senior Member
There are a few things which might cause unexpected operation. Assuming the device is working on the SPE035 module, using the same uSD card, with the same files, in the same directory will eliminate a few of them. Differing file formats, directories and quantities can change the operation of the DfPlayer enormously as loading the files can go from under a second, to almost a minute (8000+ files in directories containing 255 files per directory).

I power up the DfPlayer, wait for the five seconds recommended wait time and then set the volume to zero, attempt to play track 001.mp3, wait for half a second, check that track 001 is playing, if it isn't, attempt to play it again, repeat this a number of times until either track 001 does play or I assume track 001 does not exist and give up. If track 001 does play, I stop it, set the volume back to the correct level and carry on with the rest of my program.

When playing a track, I wait to see if it has begun to play and then check in a loop for 10-15 seconds that it continues to play. Where a large number of tracks exist on a disk, it can happen that a track appears to start (the busy line is triggered) but then almost immediately the busy line returns to the 'stopped' value and the track doesn't play. This time delay can escalate as more and more tracks are added to the disk leading to the result that none of the tracks appear to play, even though the busy status indicates they started.

It is possible to request that the DfPlayer module returns status information back to the processor. The documentation for this is rather poor but it could be possible to feed this into a terminal and read back the module status to see why *it* thinks tracks cannot be played. I use this to query the total tracks on a uSD card or USB disk making sure I don't try to play a track that is not present.

I have used these modules in a few designs and found them to be superb. I have a mini-jukebox loaded with 8000+ mp3's that I use for my AM transmitter that runs 24/7 to allow my 1950's valve radios to work, and my valve clock radios to wake me up every work day. I also have some in use at work for playing sound effects with only 10 or so tracks loaded, again very reliably.
 

steliosm

Senior Member
In order to properly init the module try setting the arg variable to $02 in order to define the source as the uSD card. You could also try pushing the volume up a bit, eg. arg=$15. This is the sequence I do after I waiting for ~2sec. for the module to initialize.
 

Ghostbear

Member
There are a few things which might cause unexpected operation. Assuming the device is working on the SPE035 module, using the same uSD card, with the same files, in the same directory will eliminate a few of them. Differing file formats, directories and quantities can change the operation of the DfPlayer enormously as loading the files can go from under a second, to almost a minute (8000+ files in directories containing 255 files per directory).

I power up the DfPlayer, wait for the five seconds recommended wait time and then set the volume to zero, attempt to play track 001.mp3, wait for half a second, check that track 001 is playing, if it isn't, attempt to play it again, repeat this a number of times until either track 001 does play or I assume track 001 does not exist and give up. If track 001 does play, I stop it, set the volume back to the correct level and carry on with the rest of my program.

When playing a track, I wait to see if it has begun to play and then check in a loop for 10-15 seconds that it continues to play. Where a large number of tracks exist on a disk, it can happen that a track appears to start (the busy line is triggered) but then almost immediately the busy line returns to the 'stopped' value and the track doesn't play. This time delay can escalate as more and more tracks are added to the disk leading to the result that none of the tracks appear to play, even though the busy status indicates they started.

It is possible to request that the DfPlayer module returns status information back to the processor. The documentation for this is rather poor but it could be possible to feed this into a terminal and read back the module status to see why *it* thinks tracks cannot be played. I use this to query the total tracks on a uSD card or USB disk making sure I don't try to play a track that is not present.

I have used these modules in a few designs and found them to be superb. I have a mini-jukebox loaded with 8000+ mp3's that I use for my AM transmitter that runs 24/7 to allow my 1950's valve radios to work, and my valve clock radios to wake me up every work day. I also have some in use at work for playing sound effects with only 10 or so tracks loaded, again very reliably.

Cool,

Now this might sound like a daft question, but for reading the serial command from the player would the best thing to do be via an interrupt so that whenever it triggers it reads the requesite number of bytes of data which either then go into variables, or is there a way of dumping it straight to the terminal?
 

hippy

Technical Support
Staff member
In order to properly init the module try setting the arg variable to $02 in order to define the source as the uSD card.
If everything is working with the SPE035 board everything should be working when it's not on that board. There will be no need to change commands, what's on the SD Card, or anything else. Software which works with the SPE035 will work with the DFPlayer Mini directly.

The problem is most likely a circuit error, possibly a mis-wiring, or a faulty change made to the software if the direct wiring is different to what the SPE035 provides.

Changing things which don't need to change will only muddy the waters, make it harder to determine what the underlying issue is.

Now this might sound like a daft question, but for reading the serial command from the player would the best thing to do be via an interrupt so that whenever it triggers it reads the requesite number of bytes of data which either then go into variables, or is there a way of dumping it straight to the terminal?
The serial data from the module isn't particularly useful. But if you want to read it a SERIN immediately after the SEROUT is what is best. Interrupts won't work; the data will be lost before the interrupt is responded to -

Code:
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArgMsb, rxArgLsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
In the overwhelming majority of cases just reading the 'busy' line is all that is required.

Again, if the software works with the SPE035, it should work with the DFPlayer Mini directly. Reading the serial data will unlikely offer any insight why it doesn't work.

In fact it will likely be a distraction rather than anything else as the detour taken to read and handle serial responses is not straight forward. Handling serial responses should be added to a working system, is unlikely to be a useful tool for diagnosing a non-working system.
 

Ghostbear

Member
In order to properly init the module try setting the arg variable to $02 in order to define the source as the uSD card. You could also try pushing the volume up a bit, eg. arg=$15. This is the sequence I do after I waiting for ~2sec. for the module to initialize.
I kinda hope it's something that simple that I've forgotten..... and I kinda don't as it's a bit of a no brainer :)
 

Ghostbear

Member
If everything is working with the SPE035 board everything should be working when it's not on that board. There will be no need to change commands, what's on the SD Card, or anything else. Software which works with the SPE035 will work with the DFPlayer Mini directly.

The problem is most likely a circuit error, possibly a mis-wiring, or a faulty change made to the software if the direct wiring is different to what the SPE035 provides.

Changing things which don't need to change will only muddy the waters, make it harder to determine what the underlying issue is.



The serial data from the module isn't particularly useful. But if you want to read it a SERIN immediately after the SEROUT is what is best. Interrupts won't work; the data will be lost before the interrupt is responded to -

Code:
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArgMsb, rxArgLsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
In the overwhelming majority of cases just reading the 'busy' line is all that is required.

Again, if the software works with the SPE035, it should work with the DFPlayer Mini directly. Reading the serial data will unlikely offer any insight why it doesn't work.

In fact it will likely be a distraction rather than anything else as the detour taken to read and handle serial responses is not straight forward. Handling serial responses should be added to a working system, is unlikely to be a useful tool for diagnosing a non-working system.
Thanks hippy,

As of last night, the busy pin was just in it's default high state, hence why I was thinking of getting the serial commands from the unit following one of the earlier posts to see what the unit thinks is wrong.
 

hippy

Technical Support
Staff member
I don't know if this will help but it's one of our test programs used for testing and developing with the AXE171+SPE035 which uses serial feedback -

Code:
#Picaxe 14M2
#Terminal 4800

;             AXE171       .------------------------------------------.
;           PICAXE-14M2    |                                          |
;          .-----------.   | -.- V+     V+ -.-   SPE035 (DFP-Mini)    |
;         -| B.5   C.0 |-  |  |             |   .-----------------.   |
;      .---| B.4   C.1 |-  |  |             `---| VCC        BUSY |---'
;      |  -| B.3   C.2 |<--'  |  .------------->| RX         USB- |-
;      |  -| B.2   C.3 |<-----|--|--------------| TX         USB+ |-
;      |  -| B.1   C.4 |-     |  |             -| DACR     ADKEY2 |-
;      |  -| B.0   C.5 |      |  |     |\  _   -| DACL     ADKEY1 |-
;   .--|---| 0V  _  V+ |------'  |     | \| |---| SPK1  ___   IO2 |-
;   |  |   `----' `----'   ___   |  8R |  | |  -| GND  |   |  GND |---.
;   |  `------------------|___|--'     | /|_|---| SPK2 |   |  IO1 |-  |
;   |                      1K0         |/  +    `------|___|------'   |
;  _|_ 0V                                                         0V _|_             

Symbol TX        = B.4
Symbol RX        = C.3
Symbol BUSY_PIN  = pinC.2

Symbol BAUD_FREQ = M16 ; Note M16
Symbol BAUD      = T9600_16

Symbol cmd       = b0

Symbol arg       = w1 ; b3:b2
Symbol arg.lsb   = b2
Symbol arg.msb   = b3

Symbol rxSom     = b10
Symbol rxVer     = b11
Symbol rxCmd     = b12
Symbol rxLen     = b13
Symbol rxFbk     = b14
Symbol rxArg.msb = b15
Symbol rxArg.lsb = b16
Symbol rxEom     = b17

High TX

; Get initial power-on response from the module
; Note there is no response after a download, only
; after download and the AXE171 is power-cycled
Gosub WaitForResponse

; Delay until Terminal is displayed
Pause 2000
SerTxd("Started", CR, LF )

; Check that USB memory / SD card is inserted
SerTxd( "Initial response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Reset the module
SerTxd("Reset the module", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse

; Check that USB memory / SD card is inserted
SerTxd( "Reset response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Get firmware version number
SerTxd("Get firmware version number", CR, LF )
cmd = $46 : Gosub SendAndWaitForResponse
SerTxd( "Firmware version response = " )
Gosub ShowResponse
SerTxd( "* Version ", #rxArg.msb, ".", #rxArg.lsb, CR, LF )

; Select the SD Card for use
SerTxd("Select TF Card", CR, LF )
cmd = $09 : arg = $0002 : Gosub Send
Pause 4000

; Set an initial volume
SerTxd("Volume 20", CR, LF )
cmd = $06 : arg = 20 : Gosub Send
Pause 1000

; Play the first song found on card
SerTxd("Play first song", CR, LF )
cmd = $03 : arg = 1 : Gosub SendAndWaitForResponse

; The program will not continue until a response has
; been received

; Report the response
; Note there is no timeout because we don't know how
; long a song will be, so no idea when a response 
; will arrive.
SerTxd( "After play response = " )
Gosub ShowResponse
If rxCmd = $3D Then
  SerTxd( "* End of song", CR, LF )
Else
  SerTxd( "* Unexpected response", CR, LF )
End If

Sertxd("Done", CR, LF )
Stop

Send:
  SetFreq BAUD_FREQ
  Pause 10
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SetFreq MDEFAULT
  arg = 0
  Return
  
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
    
WaitForResponse:
  SetFreq BAUD_FREQ
  rxSom = $7E
  SerIn  [5000,TimedOut], RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  Return
  
TimedOut:
  rxSom = $00
  SetFreq MDEFAULT
  Return
  
ShowResponse:
  b0 = rxSom     : Gosub ShowHexByte
  b0 = rxVer     : Gosub ShowHexByte
  b0 = rxLen     : Gosub ShowHexByte
  b0 = rxCmd     : Gosub ShowHexByte
  b0 = rxFbk     : Gosub ShowHexByte
  b0 = rxArg.msb : Gosub ShowHexByte
  b0 = rxArg.lsb : Gosub ShowHexByte
  b0 = rxEom     : Gosub ShowHexByte
  SerTxd( CR, LF )
  Return
    
ShowHexByte:
  b1 = b0 / $10 : Gosub ShowHexDigit
  b1 = b0       : Gosub ShowHexDigit
  SerTxd( " " )
  Return

ShowHexDigit:
  b1 = b1 & $F + "0"
  If b1 > "9" Then
    b1 = b1 + 7
  End If
  SerTxd( b1 )
  Return
That hasn't been run for a while but I recall it worked as expected. It would be worth testing that with the SPE035 before directly with the module.

I still think it's a hardware or wiring issue if it works with the SPE035 but not directly.
 

Ghostbear

Member
I don't know if this will help but it's one of our test programs used for testing and developing with the AXE171+SPE035 which uses serial feedback -

Code:
#Picaxe 14M2
#Terminal 4800

;             AXE171       .------------------------------------------.
;           PICAXE-14M2    |                                          |
;          .-----------.   | -.- V+     V+ -.-   SPE035 (DFP-Mini)    |
;         -| B.5   C.0 |-  |  |             |   .-----------------.   |
;      .---| B.4   C.1 |-  |  |             `---| VCC        BUSY |---'
;      |  -| B.3   C.2 |<--'  |  .------------->| RX         USB- |-
;      |  -| B.2   C.3 |<-----|--|--------------| TX         USB+ |-
;      |  -| B.1   C.4 |-     |  |             -| DACR     ADKEY2 |-
;      |  -| B.0   C.5 |      |  |     |\  _   -| DACL     ADKEY1 |-
;   .--|---| 0V  _  V+ |------'  |     | \| |---| SPK1  ___   IO2 |-
;   |  |   `----' `----'   ___   |  8R |  | |  -| GND  |   |  GND |---.
;   |  `------------------|___|--'     | /|_|---| SPK2 |   |  IO1 |-  |
;   |                      1K0         |/  +    `------|___|------'   |
;  _|_ 0V                                                         0V _|_             

Symbol TX        = B.4
Symbol RX        = C.3
Symbol BUSY_PIN  = pinC.2

Symbol BAUD_FREQ = M16 ; Note M16
Symbol BAUD      = T9600_16

Symbol cmd       = b0

Symbol arg       = w1 ; b3:b2
Symbol arg.lsb   = b2
Symbol arg.msb   = b3

Symbol rxSom     = b10
Symbol rxVer     = b11
Symbol rxCmd     = b12
Symbol rxLen     = b13
Symbol rxFbk     = b14
Symbol rxArg.msb = b15
Symbol rxArg.lsb = b16
Symbol rxEom     = b17

High TX

; Get initial power-on response from the module
; Note there is no response after a download, only
; after download and the AXE171 is power-cycled
Gosub WaitForResponse

; Delay until Terminal is displayed
Pause 2000
SerTxd("Started", CR, LF )

; Check that USB memory / SD card is inserted
SerTxd( "Initial response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Reset the module
SerTxd("Reset the module", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse

; Check that USB memory / SD card is inserted
SerTxd( "Reset response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Get firmware version number
SerTxd("Get firmware version number", CR, LF )
cmd = $46 : Gosub SendAndWaitForResponse
SerTxd( "Firmware version response = " )
Gosub ShowResponse
SerTxd( "* Version ", #rxArg.msb, ".", #rxArg.lsb, CR, LF )

; Select the SD Card for use
SerTxd("Select TF Card", CR, LF )
cmd = $09 : arg = $0002 : Gosub Send
Pause 4000

; Set an initial volume
SerTxd("Volume 20", CR, LF )
cmd = $06 : arg = 20 : Gosub Send
Pause 1000

; Play the first song found on card
SerTxd("Play first song", CR, LF )
cmd = $03 : arg = 1 : Gosub SendAndWaitForResponse

; The program will not continue until a response has
; been received

; Report the response
; Note there is no timeout because we don't know how
; long a song will be, so no idea when a response 
; will arrive.
SerTxd( "After play response = " )
Gosub ShowResponse
If rxCmd = $3D Then
  SerTxd( "* End of song", CR, LF )
Else
  SerTxd( "* Unexpected response", CR, LF )
End If

Sertxd("Done", CR, LF )
Stop

Send:
  SetFreq BAUD_FREQ
  Pause 10
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SetFreq MDEFAULT
  arg = 0
  Return
  
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
    
WaitForResponse:
  SetFreq BAUD_FREQ
  rxSom = $7E
  SerIn  [5000,TimedOut], RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  Return
  
TimedOut:
  rxSom = $00
  SetFreq MDEFAULT
  Return
  
ShowResponse:
  b0 = rxSom     : Gosub ShowHexByte
  b0 = rxVer     : Gosub ShowHexByte
  b0 = rxLen     : Gosub ShowHexByte
  b0 = rxCmd     : Gosub ShowHexByte
  b0 = rxFbk     : Gosub ShowHexByte
  b0 = rxArg.msb : Gosub ShowHexByte
  b0 = rxArg.lsb : Gosub ShowHexByte
  b0 = rxEom     : Gosub ShowHexByte
  SerTxd( CR, LF )
  Return
    
ShowHexByte:
  b1 = b0 / $10 : Gosub ShowHexDigit
  b1 = b0       : Gosub ShowHexDigit
  SerTxd( " " )
  Return

ShowHexDigit:
  b1 = b1 & $F + "0"
  If b1 > "9" Then
    b1 = b1 + 7
  End If
  SerTxd( b1 )
  Return
That hasn't been run for a while but I recall it worked as expected. It would be worth testing that with the SPE035 before directly with the module.

I still think it's a hardware or wiring issue if it works with the SPE035 but not directly.

Cool, thanks for that Hippy, I'll give it a whirl tonight.

And, I've just remembered that it'd be worth mentioning that the module works via the buttons on the SPE35 module, but I haven't tried it via serial command yet.... so I'll put a cable together to give that a go first and failing that I'll give the test program a shot.

Fingers crossed :)
 

hippy

Technical Support
Staff member
And, I've just remembered that it'd be worth mentioning that the module works via the buttons on the SPE35 module, but I haven't tried it via serial command yet...
Yes; that is worth mentioning.

It would be best to describe what has been tested, what works and what doesn't, using both the SPE035 and when standalone.

It would seem to be time for you to post details of what your circuit is, photos of your hardware.
 

Ghostbear

Member
Yes; that is worth mentioning.

It would be best to describe what has been tested, what works and what doesn't, using both the SPE035 and when standalone.

It would seem to be time for you to post details of what your circuit is, photos of your hardware.

A fair point. :)

At this point I'm using the spe035 sample code, just to get the thing working.
As of tonight I've for a 14m2 with minimum programming circuit and a single output that's connected to the Rx pin on the spe035 module.
Basically stripped everything down the the absolute bare bones.

The spe035 sample code has 1 change to amend the output pin to B.1 as that will be the one I'm wanting to use eventually.

As of current, the spe035 plays fine via the buttons,
When it comes to the serial commands, the led on the player flashes when it gets the initialise and volume command. But still does nothing when it comes to the play command.
Files are in an MP3 folder named 001, 002, 003

The original intention is to generate sound effects for a pp3 prop for Babylon 5 costume that also emits a modulated IR signal.

I can try and get photos later if needed?
 

Ghostbear

Member
I don't know if this will help but it's one of our test programs used for testing and developing with the AXE171+SPE035 which uses serial feedback -

Code:
#Picaxe 14M2
#Terminal 4800

;             AXE171       .------------------------------------------.
;           PICAXE-14M2    |                                          |
;          .-----------.   | -.- V+     V+ -.-   SPE035 (DFP-Mini)    |
;         -| B.5   C.0 |-  |  |             |   .-----------------.   |
;      .---| B.4   C.1 |-  |  |             `---| VCC        BUSY |---'
;      |  -| B.3   C.2 |<--'  |  .------------->| RX         USB- |-
;      |  -| B.2   C.3 |<-----|--|--------------| TX         USB+ |-
;      |  -| B.1   C.4 |-     |  |             -| DACR     ADKEY2 |-
;      |  -| B.0   C.5 |      |  |     |\  _   -| DACL     ADKEY1 |-
;   .--|---| 0V  _  V+ |------'  |     | \| |---| SPK1  ___   IO2 |-
;   |  |   `----' `----'   ___   |  8R |  | |  -| GND  |   |  GND |---.
;   |  `------------------|___|--'     | /|_|---| SPK2 |   |  IO1 |-  |
;   |                      1K0         |/  +    `------|___|------'   |
;  _|_ 0V                                                         0V _|_             

Symbol TX        = B.4
Symbol RX        = C.3
Symbol BUSY_PIN  = pinC.2

Symbol BAUD_FREQ = M16 ; Note M16
Symbol BAUD      = T9600_16

Symbol cmd       = b0

Symbol arg       = w1 ; b3:b2
Symbol arg.lsb   = b2
Symbol arg.msb   = b3

Symbol rxSom     = b10
Symbol rxVer     = b11
Symbol rxCmd     = b12
Symbol rxLen     = b13
Symbol rxFbk     = b14
Symbol rxArg.msb = b15
Symbol rxArg.lsb = b16
Symbol rxEom     = b17

High TX

; Get initial power-on response from the module
; Note there is no response after a download, only
; after download and the AXE171 is power-cycled
Gosub WaitForResponse

; Delay until Terminal is displayed
Pause 2000
SerTxd("Started", CR, LF )

; Check that USB memory / SD card is inserted
SerTxd( "Initial response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Reset the module
SerTxd("Reset the module", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse

; Check that USB memory / SD card is inserted
SerTxd( "Reset response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Get firmware version number
SerTxd("Get firmware version number", CR, LF )
cmd = $46 : Gosub SendAndWaitForResponse
SerTxd( "Firmware version response = " )
Gosub ShowResponse
SerTxd( "* Version ", #rxArg.msb, ".", #rxArg.lsb, CR, LF )

; Select the SD Card for use
SerTxd("Select TF Card", CR, LF )
cmd = $09 : arg = $0002 : Gosub Send
Pause 4000

; Set an initial volume
SerTxd("Volume 20", CR, LF )
cmd = $06 : arg = 20 : Gosub Send
Pause 1000

; Play the first song found on card
SerTxd("Play first song", CR, LF )
cmd = $03 : arg = 1 : Gosub SendAndWaitForResponse

; The program will not continue until a response has
; been received

; Report the response
; Note there is no timeout because we don't know how
; long a song will be, so no idea when a response 
; will arrive.
SerTxd( "After play response = " )
Gosub ShowResponse
If rxCmd = $3D Then
  SerTxd( "* End of song", CR, LF )
Else
  SerTxd( "* Unexpected response", CR, LF )
End If

Sertxd("Done", CR, LF )
Stop

Send:
  SetFreq BAUD_FREQ
  Pause 10
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SetFreq MDEFAULT
  arg = 0
  Return
  
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
    
WaitForResponse:
  SetFreq BAUD_FREQ
  rxSom = $7E
  SerIn  [5000,TimedOut], RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  Return
  
TimedOut:
  rxSom = $00
  SetFreq MDEFAULT
  Return
  
ShowResponse:
  b0 = rxSom     : Gosub ShowHexByte
  b0 = rxVer     : Gosub ShowHexByte
  b0 = rxLen     : Gosub ShowHexByte
  b0 = rxCmd     : Gosub ShowHexByte
  b0 = rxFbk     : Gosub ShowHexByte
  b0 = rxArg.msb : Gosub ShowHexByte
  b0 = rxArg.lsb : Gosub ShowHexByte
  b0 = rxEom     : Gosub ShowHexByte
  SerTxd( CR, LF )
  Return
    
ShowHexByte:
  b1 = b0 / $10 : Gosub ShowHexDigit
  b1 = b0       : Gosub ShowHexDigit
  SerTxd( " " )
  Return

ShowHexDigit:
  b1 = b1 & $F + "0"
  If b1 > "9" Then
    b1 = b1 + 7
  End If
  SerTxd( b1 )
  Return
That hasn't been run for a while but I recall it worked as expected. It would be worth testing that with the SPE035 before directly with the module.

I still think it's a hardware or wiring issue if it works with the SPE035 but not directly.
Ok, so using this code and only changing the pin used for the output (from B.4 to B.1) I get:

Code:
Started
Initial response = No response
Reset the module
Reset response = 7E FF 06 40 00 00 03 FE 
* Unexpected response
Get firmware version number
Firmware version response = 7E FF 06 40 00 00 03 FE 
* Version 0.3
Select TF Card
Volume 20
Play first song
After play response = 7E FF 06 40 00 00 03 FE 
* Unexpected response
Done
Now looking online, this appears to be "Serial receiving error(a frame has not been received completely yet)" Which I have no idea how to sort out

But, it does explain why it'll play via the buttons if theres problems wit the serial comms...

If anyone needs me, I'll be over here, banging my head against a wall....
 

tmfkam

Senior Member
I don't know if this will help but it's one of our test programs used for testing and developing with the AXE171+SPE035 which uses serial feedback -

Code:
#Picaxe 14M2
#Terminal 4800

;             AXE171       .------------------------------------------.
;           PICAXE-14M2    |                                          |
;          .-----------.   | -.- V+     V+ -.-   SPE035 (DFP-Mini)    |
;         -| B.5   C.0 |-  |  |             |   .-----------------.   |
;      .---| B.4   C.1 |-  |  |             `---| VCC        BUSY |---'
;      |  -| B.3   C.2 |<--'  |  .------------->| RX         USB- |-
;      |  -| B.2   C.3 |<-----|--|--------------| TX         USB+ |-
;      |  -| B.1   C.4 |-     |  |             -| DACR     ADKEY2 |-
;      |  -| B.0   C.5 |      |  |     |\  _   -| DACL     ADKEY1 |-
;   .--|---| 0V  _  V+ |------'  |     | \| |---| SPK1  ___   IO2 |-
;   |  |   `----' `----'   ___   |  8R |  | |  -| GND  |   |  GND |---.
;   |  `------------------|___|--'     | /|_|---| SPK2 |   |  IO1 |-  |
;   |                      1K0         |/  +    `------|___|------'   |
;  _|_ 0V                                                         0V _|_             

Symbol TX        = B.4
Symbol RX        = C.3
Symbol BUSY_PIN  = pinC.2

Symbol BAUD_FREQ = M16 ; Note M16
Symbol BAUD      = T9600_16

Symbol cmd       = b0

Symbol arg       = w1 ; b3:b2
Symbol arg.lsb   = b2
Symbol arg.msb   = b3

Symbol rxSom     = b10
Symbol rxVer     = b11
Symbol rxCmd     = b12
Symbol rxLen     = b13
Symbol rxFbk     = b14
Symbol rxArg.msb = b15
Symbol rxArg.lsb = b16
Symbol rxEom     = b17

High TX

; Get initial power-on response from the module
; Note there is no response after a download, only
; after download and the AXE171 is power-cycled
Gosub WaitForResponse

; Delay until Terminal is displayed
Pause 2000
SerTxd("Started", CR, LF )

; Check that USB memory / SD card is inserted
SerTxd( "Initial response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Reset the module
SerTxd("Reset the module", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse

; Check that USB memory / SD card is inserted
SerTxd( "Reset response = " )
If rxSom = $00 Then
  SerTxd( "No response", CR, LF )
Else
  Gosub ShowResponse
  If rxCmd <> $3F Then
    SerTxd( "* Unexpected response", CR, LF )
  Else
    b0 = rxArg.lsb
    If bit0 = 1 Then ; $01
      SerTxd( "* USB memory detected", CR, LF )
	rxCmd = $00
    End If
    If bit1 = 1 Then ; $02
      SerTxd( "* SD Card detected", CR, LF )
	rxCmd = $00
    End If
    If bit2 = 1 Then ; $02
      SerTxd( "* PC connection detected", CR, LF )
	rxCmd = $00
    End If
    If rxCmd <> $00 Then
      SerTxd( "* Unknown source detected", CR, LF )
    End If
  End If
End If

; Get firmware version number
SerTxd("Get firmware version number", CR, LF )
cmd = $46 : Gosub SendAndWaitForResponse
SerTxd( "Firmware version response = " )
Gosub ShowResponse
SerTxd( "* Version ", #rxArg.msb, ".", #rxArg.lsb, CR, LF )

; Select the SD Card for use
SerTxd("Select TF Card", CR, LF )
cmd = $09 : arg = $0002 : Gosub Send
Pause 4000

; Set an initial volume
SerTxd("Volume 20", CR, LF )
cmd = $06 : arg = 20 : Gosub Send
Pause 1000

; Play the first song found on card
SerTxd("Play first song", CR, LF )
cmd = $03 : arg = 1 : Gosub SendAndWaitForResponse

; The program will not continue until a response has
; been received

; Report the response
; Note there is no timeout because we don't know how
; long a song will be, so no idea when a response 
; will arrive.
SerTxd( "After play response = " )
Gosub ShowResponse
If rxCmd = $3D Then
  SerTxd( "* End of song", CR, LF )
Else
  SerTxd( "* Unexpected response", CR, LF )
End If

Sertxd("Done", CR, LF )
Stop

Send:
  SetFreq BAUD_FREQ
  Pause 10
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SetFreq MDEFAULT
  arg = 0
  Return
  
SendAndWaitForResponse:
  SetFreq BAUD_FREQ
  Pause 10
  rxSom = $7E
  SerOut TX, BAUD, ( $7E, $FF, $06, cmd, $00, arg.msb, arg.lsb, $EF )
  SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  arg = 0
  Return
    
WaitForResponse:
  SetFreq BAUD_FREQ
  rxSom = $7E
  SerIn  [5000,TimedOut], RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
  SetFreq MDEFAULT
  Return
  
TimedOut:
  rxSom = $00
  SetFreq MDEFAULT
  Return
  
ShowResponse:
  b0 = rxSom     : Gosub ShowHexByte
  b0 = rxVer     : Gosub ShowHexByte
  b0 = rxLen     : Gosub ShowHexByte
  b0 = rxCmd     : Gosub ShowHexByte
  b0 = rxFbk     : Gosub ShowHexByte
  b0 = rxArg.msb : Gosub ShowHexByte
  b0 = rxArg.lsb : Gosub ShowHexByte
  b0 = rxEom     : Gosub ShowHexByte
  SerTxd( CR, LF )
  Return
    
ShowHexByte:
  b1 = b0 / $10 : Gosub ShowHexDigit
  b1 = b0       : Gosub ShowHexDigit
  SerTxd( " " )
  Return

ShowHexDigit:
  b1 = b1 & $F + "0"
  If b1 > "9" Then
    b1 = b1 + 7
  End If
  SerTxd( b1 )
  Return
That hasn't been run for a while but I recall it worked as expected. It would be worth testing that with the SPE035 before directly with the module.

I still think it's a hardware or wiring issue if it works with the SPE035 but not directly.
Rats! That would have been so useful for me when I was developing my software. As it was I had to insert an inline serial monitor using an LCD display to show the commands sent and received.

Mind you, most of my problems were resolved when I got the hang of sending the correct command, to match the file names and directory structure on the disk. There are different commands for placing files in a directory "mp3" and another command for playing files in a directory "01". In each case, the files themselves may also need naming differently too. The 'play' button ignores these subtleties and just plays anything...
 

Ghostbear

Member
So, I've also managed to find a little more info:

"Normally it’s okay whether users choose to use checksum or not, our module can receive a serial data with or without checksum, but some of users use a MCU without crystal oscillator, so if in that case we strongly suggest users to add checksum to make sure the communication stability."

So, combining that with the error code suggests I need to add the checksum to the command.

Thoughts?
 

Ghostbear

Member
Rats! That would have been so useful for me when I was developing my software. As it was I had to insert an inline serial monitor using an LCD display to show the commands sent and received.

Mind you, most of my problems were resolved when I got the hang of sending the correct command, to match the file names and directory structure on the disk. There are different commands for placing files in a directory "mp3" and another command for playing files in a directory "01". In each case, the files themselves may also need naming differently too. The 'play' button ignores these subtleties and just plays anything...
It is handy bit of code aint it :)

Thing is, it's giving the error message on the initialisation so the problem seems to be the comms
 

hippy

Technical Support
Staff member
Thing is, it's giving the error message on the initialisation so the problem seems to be the comms
The module is responding to the Reset and Play commands sent, albeit not with the response being as expected, and it is responding as expected to the Get Firmware command, with a response which is as expected.

From that I would say it is not a comms problem per se.

I am not sure what the "7E FF 06 40 00 00 03 FE" response actually means because it is not in the datasheet I have and I have not found anything definitive online.

It would be useful to know what the "Started/Initial Response=" is when you power-cycle the PICAXE and DFPlayer module.
 

Ghostbear

Member
The module is responding to the Reset and Play commands sent, albeit not with the response being as expected, and it is responding as expected to the Get Firmware command, with a response which is as expected.

From that I would say it is not a comms problem per se.

I am not sure what the "7E FF 06 40 00 00 03 FE" response actually means because it is not in the datasheet I have and I have not found anything definitive online.

It would be useful to know what the "Started/Initial Response=" is when you power-cycle the PICAXE and DFPlayer module.

Hi Hippy,

Try this one: Datasheet

Its a slightly different overall module, but the core chipset is the same as the DFplayer and the serial comms protocols are identical - just this one has a little more detail about the various returned codes etc.

So - 7E FF 06 40 00 00 03 xx xx EF Serial receiving error(a frame has not been received completely yet)
 
Last edited:

hippy

Technical Support
Staff member
Added: Looks like our posts crossed while I was digging deeper ...

I found a couple of datasheets which appears to use the same IC as the DFPlayer which provides a more extensive list of error codes ...

http://www.electronics123.net/amazon/datasheet/FN-BC04 MP3 Sound Module with 10W Amplifier User's Manual.pdf

http://caxapa.ru/thumbs/815852/MP3-Flash-10P.pdf

Code:
7E FF 06 [b]40 00 00 [i]nn[/i][/b] EF

01 - Module busy (this info is returned when the initialization is not done)
02 - Currently sleep mode (supports only specified device in sleep mode)
03 - Serial receiving error (a frame has not been received completely yet)
04 - Checksum incorrect
05 - Specified track is out of current track scope
06 - Specified track is not found
07 - Inter-cut error (an inter-cut operation only can be done when a track is being played )
08 - SD card reading failed (SD card pulled out or damaged)
0A - Entered in to sleep mode
So that, and similar in other module datasheets, does appear to confirm "Serial receiving error (a frame has not been received completely yet)", but as to what that actually means, what has to be done to avoid or rectify that I am not sure.

It is hard to believe it is simply later firmware requiring something different to what old versions expected as that would break existing software, would prevent the new version being a drop-in for the old.

The only ways I can think of progressing are to (1) try a different SD card in case it is card related, (2) add delays between commands, (3) report the replies returned which are not currently reported, (4) add Query Status, Volume, EQ commands to see how they respond, (5) add other commands to see how they respond.

It would be possible to send with checksums rather than without but it seems unlikely that would make a difference seeing as Get Firmware Version works as expected without.
 

Ghostbear

Member
Added: Looks like our posts crossed while I was digging deeper ...

I found a couple of datasheets which appears to use the same IC as the DFPlayer which provides a more extensive list of error codes ...

http://www.electronics123.net/amazon/datasheet/FN-BC04 MP3 Sound Module with 10W Amplifier User's Manual.pdf

http://caxapa.ru/thumbs/815852/MP3-Flash-10P.pdf

Code:
7E FF 06 [b]40 00 00 [i]nn[/i][/b] EF

01 - Module busy (this info is returned when the initialization is not done)
02 - Currently sleep mode (supports only specified device in sleep mode)
03 - Serial receiving error (a frame has not been received completely yet)
04 - Checksum incorrect
05 - Specified track is out of current track scope
06 - Specified track is not found
07 - Inter-cut error (an inter-cut operation only can be done when a track is being played )
08 - SD card reading failed (SD card pulled out or damaged)
0A - Entered in to sleep mode
So that, and similar in other module datasheets, does appear to confirm "Serial receiving error (a frame has not been received completely yet)", but as to what that actually means, what has to be done to avoid or rectify that I am not sure.

It is hard to believe it is simply later firmware requiring something different to what old versions expected as that would break existing software, would prevent the new version being a drop-in for the old.

The only ways I can think of progressing are to (1) try a different SD card in case it is card related, (2) add delays between commands, (3) report the replies returned which are not currently reported, (4) add Query Status, Volume, EQ commands to see how they respond, (5) add other commands to see how they respond.

It would be possible to send with checksums rather than without but it seems unlikely that would make a difference seeing as Get Firmware Version works as expected without.
I feel perversely proud that I've found dome thing that has you stumped Hippy :)

I'll try the other stuff tonight, but I've already tried 3 different cards/2 different makes to see if that helped.

Hey-ho, time for thd equivalent of "push ALL the buttons and figure out what heppens" :)
 

Ghostbear

Member
Do looking at framing errors:

Code:
Generally, a framing error is the result of starting to read a sequence of data at the wrong point.
In serial communications, a framing error is the result of reading a data frame -- a string of symbols which are grouped in blocks -- at the wrong starting point. The symbols are bits and the blocks are bytes, ten bits in asynchronous transmission and eight in synchronous. A framing error in an asynchronous stream usually recovers quickly, but a framing error in a synchronous stream produces gibberish at the end of the packet. Framing errors can be detected with parity bits.
So, it may be potentially how the picaxe is sending the data, even though it's set at the correct Baud rate. Could it be something as simple as the oscillator on the picaxe is out by just enough, I've got a couple spare 14M2 chips I can try.

Also:
Code:
Possible causes of frame error

1] Your baud rate at sender and receiver are very different, so the receiver (i.e. the PIC) is sampling each bit earlier and earlier, so it sometimes sees the end of the 8th bit instead of the middle of the stop bit.

[2] Your sender is sending 9 bits of data, not 8. This could be if it is set to send 8 data bits + a parity bit.

[3] You have a lot of noise on the signal.

I'm wondering if theres a bit of a difference on the baud rate (not much, but enough to throw it off?)

as looking at the results:

(This is after download AND picaxe has been powered off and back on)
Ok, so initial wait for response comes back with &#8220;No response&#8221;
Which means either the module is not sending anything, or as it&#8217;s reporting that RxSom (Which is set in the WaitForResponse subroutine to $7E is reporting as zero, I wonder if what it&#8217;s reading into exSom is a couple bytes later with one of the zeroes so I&#8217;m going to try removing the qualifier, so the line goes from
Code:
SerIn  RX, BAUD, ( rxSom ), rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
/code]
To
[code]
SerIn  RX, BAUD,  rxSom , rxVer, rxLen, rxCmd, rxFbk, rxArg.msb, rxArg.lsb, rxEom
and see what that does
 

hippy

Technical Support
Staff member
looking at framing errors:
I would not completely agree with their description or likely cause, and the actual error, assuming the datasheet has it correct, is "Serial receiving error (a frame has not been received completely yet)".

That's not specifically saying there has been a "framing error" but that a frame has not been received completely. That could be because not enough data was sent, it missed some data, or the data doesn't match what it was expecting.

'It didn't get what it expected to get' is a fair enough assessment but we don't know what it found wrong with what was sent.

I'm wondering if theres a bit of a difference on the baud rate (not much, but enough to throw it off?)
That seems unlikely to me but it would be worth trying different 14M2's to confirm that.

Whenever I have measured on-chip oscillator accuracy of PICAXE chips they have always been 'spot on' for me. While there are some variances with serial bit timings they are well within acceptable tolerance.

(This is after download AND picaxe has been powered off and back on)
Ok, so initial wait for response comes back with &#8220;No response&#8221;
That is not what would be expected and is odd. The PICAXE waits for a response immediately on starting so it seems nothing is received within the timeout period.

Perhaps try changing the [5000,TimedOut] to [65000,TimedOut] in the 'WaitForResponse:' routine.

I would ignore that issue for now and look at why the response is not correct fro the later Reset command.

You could put the sending of Reset and reporting its result in a loop with a PAUSE 1000 at the end; repeatedly issuing that Reset to see if the results are consistent.

I&#8217;m going to try removing the qualifier
Worth a punt but don't get distracted in doing that and head off down a blind alley. The initial "no response" seems rather unimportant and it would be better to concentrate on why the Reset doesn't work as expected.

A better option to removing the qualifier would be to tee the data signal from the DFPlayer into a PC serial port to see exactly what is being sent.

That would be easy to do on an AXE091 board which has a MAX3232 which will invert the signal to RS232. It may be a bit difficult otherwise. A separate X2 could read the T9600 with background receive and send that out via SERTXD.
 

Ghostbear

Member
Looking at the reset the module section on the code:

Code:
; Reset the module
SerTxd("Reset the module", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse
$3F is to query the memory according to the datasheet

Code:
When the module is working, users can use the command as above (0x3F) to query the status of the online
storage devices.
$0C is to reset the module, so to reset the module I would have thought the code would be

Code:
SerTxd("Reset the module", CR, LF )
cmd = $0C : arg = 0 : Gosub SendAndWaitForResponse
SerTxd("Query the status", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse
 

hippy

Technical Support
Staff member
Code:
Get firmware version number
Firmware version response = 7E FF 06 40 00 00 03 FE 
* Version 0.3
Sorry; only just realised that isn't a valid Get Firmware Version response.

So it does appear that every command is giving a 'something is wrong' response.

$0C is to reset the module, so to reset the module I would have thought the code would be

Code:
SerTxd("Reset the module", CR, LF )
cmd = $0C : arg = 0 : Gosub SendAndWaitForResponse
SerTxd("Query the status", CR, LF )
cmd = $3F : arg = %1111 : Gosub SendAndWaitForResponse
It appears you are right there. Whether it should be a 'SendAndWaitForResponse' after $0C or simply a 'Send' then PAUSE, and for how long, I don't know.
 

hippy

Technical Support
Staff member
(This is after download AND picaxe has been powered off and back on)
Are you power-cycling the DFPlayer at the same time you are power-cycling the PICAXE ?

I'm just wondering if the DFPlayer isn't in a reset state, has got itself into some odd mode it won't come out of.
 

Ghostbear

Member
Are you power-cycling the DFPlayer at the same time you are power-cycling the PICAXE ?

I'm just wondering if the DFPlayer isn't in a reset state, has got itself into some odd mode it won't come out of.
VICTORY!

Turns out the "optional" checksums..... Aren't.

Wonder who we can mail to see about updating the documentation for the spe035?

Thanks for all the help people :)
 

hippy

Technical Support
Staff member
That's good to hear.


Turns out the "optional" checksums..... Aren't.
That's not so good.


Wonder who we can mail to see about updating the documentation for the spe035?
No need to mail us as you have made us aware of the issue.

But before we start changing documentation and the example programs, we first need to find out what the full situation is, whether this is just an anomaly or something which has changed with the DFPlayer or its chip.

Am I correct in assuming that as you have an SPE035 and DFPlayer you bought them as a pair direct from ourselves ?

Was this a recent purchase or sometime in the past ?

Can you tell us what labelling there is on the larger chip under the board to confirm it's a VX5200 chip or something else.

And can you tell us what Firmware Version is being reported when the program runs.

It would also be appreciated if you could post your test code which now works.

One thing which would be worth checking is whether it is only the first command which needs a checksum or all subsequent commands. It might be worthwhile trying the program without checksums again ( download but don't power-cycle ) to see if that now works as expected.

I know that's a bit of an ask but it sure would be appreciated in helping us figure out what is going on. We will also be looking at what we can do to sort things out this end.

And finally; sorry you had the problems but thanks for your patience, effort and feedback in getting to where we are.
 

Ghostbear

Member
That's good to hear.




That's not so good.




No need to mail us as you have made us aware of the issue.

But before we start changing documentation and the example programs, we first need to find out what the full situation is, whether this is just an anomaly or something which has changed with the DFPlayer or its chip.

Am I correct in assuming that as you have an SPE035 and DFPlayer you bought them as a pair direct from ourselves ?

Was this a recent purchase or sometime in the past ?

Can you tell us what labelling there is on the larger chip under the board to confirm it's a VX5200 chip or something else.

And can you tell us what Firmware Version is being reported when the program runs.

It would also be appreciated if you could post your test code which now works.

One thing which would be worth checking is whether it is only the first command which needs a checksum or all subsequent commands. It might be worthwhile trying the program without checksums again ( download but don't power-cycle ) to see if that now works as expected.

I know that's a bit of an ask but it sure would be appreciated in helping us figure out what is going on. We will also be looking at what we can do to sort things out this end.

And finally; sorry you had the problems but thanks for your patience, effort and feedback in getting to where we are.
No problem :) might not be for a couple weeks while I finish off the prototypes in time for the May bank holiday weekend though...
 

tmfkam

Senior Member
A better option to removing the qualifier would be to tee the data signal from the DFPlayer into a PC serial port to see exactly what is being sent.
That was the approach I took. I had a serial LCD module (running modified software to frame the hex values and display them) tapped into the PicAxe TX and (once playing started to work) then into the RX lines to 'watch' the serial communicaion going in and out. This was simply inserted on a small section of VERO board between the MP3 module on the SPE035 and the PicAxe on the oher half. Invalulable for me.

That code might have saved some scratching of the head though....
 

tmfkam

Senior Member
VICTORY!

Turns out the "optional" checksums..... Aren't.

Thanks for all the help people :)
Pleased to hear it is working at last. Well done for sticing with it.
I think I do send something relevant in the checksum sections, not sure what without looking at my code, not '00' though?
 
Top