Boot on a Delfino f2837Xs custom board with EMIF

Hi,

Besides, one of the selections pins GPIO72 is used in EMIF as EM1D12, so how is it possible to choose the boot mode with SDRAM EMIF? Using a pull-up or pull-down is enough?

Yes, pull-up or pull-down should be good enough.

On the other hand, a second doubt we have is that we would like to protect our software inside the DSP. We have been using this in the Tiva family by writting into some register. I have seen in F2837X family, you do it by using OTP with JTAG. Is it possible to protect the software/flash from our program via code?

Yes, we have DCSM module on this device for security. User can protect their code by using 128bit programmable passwords. Please refer DCSM section in device document for more detail. You can have security setting part of .out file and program the same along with code. You can refer "blinky_with_DCSM" example in controlSUITE to see how this can be done.

If a password is lost/forgotten, is there a way to erase the content on the chip and recover it? (Like unlock in Tiva family).

This device does not have such feature. Security settings are stored in OTP (one time programmable) flash which can not be erased and to change the security setting one need to know the password.

Regards,

Vivek Singh

Thank you Vivek, I really appreciate your help.

PAk said:

 As I said in other posts, we are using the EMIF port to interface a 512MB 16-bit SDRAM memory, and as I am finding a lot of "collisions" between EMIF and boot pins.

Our first idea was to program the boards (flash programming) via JTAG or SCI, however we found SCI is no possible because  GPIO85 (EM1D0) is blocked for SCIBOOT0 and GPIO29 (EM1SDCKE) is blocked for SCIBOOT1. The same happens for I2C for GPIO32 and GPIO92.

So, why that bad selection between SCI and EMIF pins for programming/Boot ? Is there any way we could program via SCI easily?

Vivek Singh said:

Yes, we have DCSM module on this device for security. User can protect their code by using 128bit programmable passwords. Please refer DCSM section in device document for more detail. You can have security setting part of .out file and program the same along with code. You can refer "blinky_with_DCSM" example in controlSUITE to see how this can be done.

Besides that, is it possible to use DCSM via JTAG or SPI without including it in the code?

I have seen a lot of questions about this issue in the forum, why not write a small note app as a guide? Actually, the module is not very intuitive itself.

Vivek Singh said:

If a password is lost/forgotten, is there a way to erase the content on the chip and recover it? (Like unlock in Tiva family).

This device does not have such feature. Security settings are stored in OTP (one time programmable) flash which can not be erased and to change the security setting one need to know the password.

Quite dangerous!!!... so if  somebody makes something wrong programming it, energy fails or this somebody messes up with the board, the only thing we could do is  just throw it away?

We are building an expensive board for doing that. ...is there any way to just erase the memory and recover the chip as a blank one?

Best regards

Hi,

So, why that bad selection between SCI and EMIF pins for programming/Boot ? Is there any way we could program via SCI easily?

 We had to use some pins as BOOT PINS and all the pins are muxed with some other functions. And you can use the pulls to control the BOOT so it's not that bad. You could also change the BOOTPIN by programming the BOOTCTRL location in OTP (under security settings). Refer "Table 3-4. BOOTCTRL Register Bit Definition for CPU1" of TRM.

Besides that, is it possible to use DCSM via JTAG or SPI without including it in the code?

Once it's part of .out, you can program it via any program loader. Right? Or, did I not understand the question?

I have seen a lot of questions about this issue in the forum, why not write a small note app as a guide? Actually, the module is not very intuitive itself.

Good feedback. We have some plan for the same. 

 Quite dangerous!!!... so if  somebody makes something wrong programming it, energy fails or this somebody messes up with the board, the only thing we could do is  just throw it away?

We do have PSWDLOCK feature to take care of such issue. Unless user programs this field, passwords are visible to user even after device is secure. So incase wrong value is programmed, user can always read the password and unlock the device. But Yes, once PSWDLOCK is programmed then one has to remember the passwords.

  We are building an expensive board for doing that. ...is there any way to just erase the memory and recover the chip as a blank one?

No way to do that without knowing password.

I would suggest to go through the DCSM section in TRM to have good understanding of security features on this device.

Regards,

Vivek Singh

Vivek Singh said:

 We had to use some pins as BOOT PINS and all the pins are muxed with some other functions. And you can use the pulls to control the BOOT so it's not that bad. You could also change the BOOTPIN by programming the BOOTCTRL location in OTP (under security settings). Refer "Table 3-4. BOOTCTRL Register Bit Definition for CPU1" of TRM.

Actullay, we don't have a big issue with the Boot Mode pins, but with the boot programming ports for example, SCIBoot is not available for us. Is there any way to move those pins for SCI programming?

Vivek Singh said:

Besides that, is it possible to use DCSM via JTAG or SPI without including it in the code?

Once it's part of .out, you can program it via any program loader. Right? Or, did I not understand the question?

I meant, if we didn't include that DSCM in the program, would it possible to just upload a regular out file (no security included in the code), and then lock/secure the code via Jtag or SPI?

Vivek Singh said:

I have seen a lot of questions about this issue in the forum, why not write a small note app as a guide? Actually, the module is not very intuitive itself.

Good feedback. We have some plan for the same. 

I really enjoy to hear that. I am waiting for that guide.

Vivek Singh said:

We do have PSWDLOCK feature to take care of such issue. Unless user programs this field, passwords are visible to user even after device is secure. So incase wrong value is programmed, user can always read the password and unlock the device. But Yes, once PSWDLOCK is programmed then one has to remember the passwords.

  We are building an expensive board for doing that. ...is there any way to just erase the memory and recover the chip as a blank one?

No way to do that without knowing password.

I would suggest to go through the DCSM section in TRM to have good understanding of security features on this device.

Would it be possible to modify the bootloader, so if some GPIO pins are grounded at boot, the board erases itself, no matter what security is? If it is, could you point to a (similar) example for this?

Would it be possible to send a command via SCI to the board,and do the same, inside my program (not at bootloaders)?

Regards

Hi,

Actullay, we don't have a big issue with the Boot Mode pins, but with the boot programming ports for example, SCIBoot is not available for us. Is there any way to move those pins for SCI programming?

Ok, I see. We have only two pinmux options for SCI BOOT and in both case pins are muxed with EMIF. So not much option there. SCI BOOT "Option 1" could still be used because it is muxed with EM1D0 pin and not with control. So as long as external UART device tri-state the SCIRXDA pin after BOOT, it may be ok. 

I meant, if we didn't include that DSCM in the program, would it possible to just upload a regular out file (no security included in the code), and then lock/secure the code via Jtag or SPI?

Yes, this should be possible.

Would it be possible to modify the bootloader, so if some GPIO pins are grounded at boot, the board erases itself, no matter what security is? If it is, could you point to a (similar) example for this?

Not possible. Are you looking for option for firmware upgrade? If yes then you can always keep Flash API in one of the secure flash sector and call these API from your BOOTLOADER to program new image in flash without unlocking the device (kind of secure firmware upgrade). But you'll not be able to disable the security without knowing the password values.

Would it be possible to send a command via SCI to the board,and do the same, inside my program (not at bootloaders)?

Same as last point.

Regards,

Vivek Singh

Thank you Vivek, this thread is actually very useful to us.

Vivek Singh said:

Would it be possible to modify the bootloader, so if some GPIO pins are grounded at boot, the board erases itself, no matter what security is? If it is, could you point to a (similar) example for this?

Not possible. Are you looking for option for firmware upgrade? If yes then you can always keep Flash API in one of the secure flash sector and call these API from your BOOTLOADER to program new image in flash without unlocking the device (kind of secure firmware upgrade). But you'll not be able to disable the security without knowing the password values.

Do you have an example for this way of upgrading firmware via Flash API? 

Is it possible to use FLASH API from my program (avoiding changing bootloader)?

Thank you again

Hi,

Do you have an example for this way of upgrading firmware via Flash API?

We do not have example code for this right now.

Is it possible to use FLASH API from my program (avoiding changing bootloader)?

I did not understand this question? You need to include the flash API in your code and place it in to secure sector. And call the API from your bootloader (based on specific boot command) to do firmware upgrade.

Regards,

Vivek Singh